[SIP Beyond VoIP] SylkServer not forwarding XMPP messages to SIP Proxy
david.hubbard at agenor.co.uk
Fri Oct 4 11:03:43 CEST 2013
"I'm not familiar with your setup, but what that option expresses is for
what domains the SylkServer instance would act as the authoritative XMPP
I think the issue is that I am proposing to use SylkServer the other way
round - we are XMPP centric trying to reach out to SIP world - and hence
had expected this to be "what domains SylkServer would act as the
authoritive SIP Server for" i.e. proxy infront of our XMPP domain.
It's possible that I may be bending the usage of SylkServer here - my
take is that (in the code) the assumption is possibly that on a send
"originator" = "sip domain" and in my case it's the other way round.
Obviously we have the work-around of putting both parties domain names
in to config - but perhaps a future enhancement might consider this
alternative use case.
"You mean outbound_proxy, right?"
I suspect I do - can't check my config right now, but certainly my final
config sends correctly.
"Check my reply, if your resolver cannot reach sip2sip.info to validate
proper NAPTR record resolution we fallback to Google's nameservers
Sorry your reply to my Blink question - I didn't get that. Right I
understand now - I hadn't quite picked up on importance of NAPTR I'll
have a look at that.
Thanks a lot
On 04/10/2013 09:20, Saúl Ibarra Corretgé wrote:
> On Oct 3, 2013, at 3:36 PM, David Hubbard wrote:
>> I have now resolved this - but a couple of things arise.
>> Firstly in terms of resolution the "domains" within "xmppgateway.ini" needed to include my target domain name (myexternal.com) even though this isn't an XMPP domain (it's SIP)
>> domains = myinternal.com,myexternal.com
>> I don't know if this is intended - the text says "Comma-separated list of Internet domains for which this server is responsible" - is SylkServer 'responsible' for all the domains that source XMPP users might connect to? - in my scenario (XMPP internal and SIP external via SIP Gateway) I was figuring that it was the SIP Gateway that was dealing with the external domains.
> I'm not familiar with your setup, but what that option expresses is for what domains the SylkServer instance would act as the authoritative XMPP server. So, for sip2sip.info, for example we have SIP infrastructure in place and our SylkServer is configured with domains=sip2sip.info, and the proper DNS records are published. This setting is required so that SylkServer know what traffic he is supposed to handle. So, if you have a XMPP account in jabber.org and contact a sip2sip.info user, SylkServer will handle it, but if you would use any other domain which ended up on the same machine, SylkServer would reject the traffic. I hope it's clearer now :-)
>> As it stands this list would need to include all the SIP domains that the source XMPP users might want to connect to - is that correct? I can see that it might be useful to be able to force validation of source and target domains (from a lock-down point of view), but should these be an optional configuration items defaulting to false?.
>> After a deal of deep tracing I've found that this error is being raised deep with the wokkel code (base XMPP Server code).
>> In XMPPServerListenAuthenticator.onVerify
>> originatingServer = jid.JID(verify['to']).host
>> if originatingServer not in self.service.domains:
>> raise error.StreamError('host-unknown')
>> Following that I've then found that host entry in the "outbound_gateway" can be an IP address (as my original) but not an internal domain name, while it can be an external domain name. With the internal domain name I get:
> You mean outbound_proxy, right?
>> [xmppgateway] DNS lookup error while looking for sip:sipgateway.myinternal.com:5060;transport=udp proxy
>> As my SIP Gateway is an internally hosted box I was expecting that it would use the local machine domain name server and not those of my default gateway. This is similar to a question I posed on Blink forum - as client appears to do the same.
> Check my reply, if your resolver cannot reach sip2sip.info to validate proper NAPTR record resolution we fallback to Google's nameservers automatically.
> Saúl Ibarra Corretgé
> AG Projects
More information about the SIPBeyondVoIP