Hello:
We are running ser 0.9.7-pre3 and seeing some strange behavior. I'm hoping someone on this list might have some input.
Our SIP domain name is actually an SRV service name that points to two A records. This configuration has existed for years and has worked reliably.
_sip._udp.myserver.myschool.edu _sip._udp.myserver.myschool.edu service = 1 5 5060 proxy1.myschool.edu. _sip._udp.myserver.myschool.edu service = 3 5 5060 proxy1.myschool.edu.
The "myserver.myschool.edu" name is not the real name it is just for discussion purposes. The name "myserver.myschool.edu" has other SRV records associated with it. For example:
$nslookup
set type=SRV _kerberos._udp.myserver.myschool.edu
_kerberos._udp.net.isc.upenn.edu service = 0 100 88 trixie.myserver.myschool.edu _kerberos._udp.net.isc.upenn.edu service = 0 100 88 pops.myserver.myschool.edu
In the past month we upgraded to this release of SER and noticed a problem when users call forward their extension to an off campus PSTN number.
If the Call Forward Always flag is set to Y then the R-URI is re-written to be a new user portion with our SIP domain name appended as the hostname. In some ngrep traces I'm seeing our proxy trying to send the forwarded call to a next hop address of "pops.myserver.myschool.edu" as shown above. The problem is pops is not a SIP server.
The only connection between our SIP environment and the host pops is the domain name. This suggests an issue with SRV resolution but I do not see the problem in my traces. Does anyone have any thoughts on this issue?
Thanks,Steve
Steve Blair wrote:
Hello:
We are running ser 0.9.7-pre3 and seeing some strange behavior. I'm hoping someone on this list might have some input.
Our SIP domain name is actually an SRV service name that points to two A records. This configuration has existed for years and has worked reliably.
_sip._udp.myserver.myschool.edu _sip._udp.myserver.myschool.edu service = 1 5 5060 proxy1.myschool.edu. _sip._udp.myserver.myschool.edu service = 3 5 5060 proxy1.myschool.edu.
The "myserver.myschool.edu" name is not the real name it is just for discussion purposes. The name "myserver.myschool.edu" has other SRV records associated with it. For example:
$nslookup > set type=SRV
_kerberos._udp.myserver.myschool.edu
_kerberos._udp.net.isc.upenn.edu service = 0 100 88 trixie.myserver.myschool.edu _kerberos._udp.net.isc.upenn.edu service = 0 100 88 pops.myserver.myschool.edu
In the past month we upgraded to this release of SER and noticed a problem when users call forward their extension to an off campus PSTN number.
If the Call Forward Always flag is set to Y then the R-URI is re-written to be a new user portion with our SIP domain name appended as the hostname. In some ngrep traces I'm seeing our proxy trying to send the forwarded call to a next hop address of "pops.myserver.myschool.edu" as shown above. The problem is pops is not a SIP server.
Use ngrep to watch also the DNS lookups (ngrep port 5060 or port 53) and verify what ser really looks up in DNS. The kerberos SRV entries must not interfere, but they are in a different domain, thus when looking up _sip._udp.... the kerberos entries should never be seen by ser.
regards klaus
The only connection between our SIP environment and the host pops is the domain name. This suggests an issue with SRV resolution but I do not see the problem in my traces. Does anyone have any thoughts on this issue?
Thanks,Steve
Klaus Darilion wrote:
Steve Blair wrote:
Hello:
We are running ser 0.9.7-pre3 and seeing some strange behavior. I'm hoping someone on this list might have some input.
Our SIP domain name is actually an SRV service name that points to two A records. This configuration has existed for years and has worked reliably.
_sip._udp.myserver.myschool.edu _sip._udp.myserver.myschool.edu service = 1 5 5060 proxy1.myschool.edu. _sip._udp.myserver.myschool.edu service = 3 5 5060 proxy1.myschool.edu.
The "myserver.myschool.edu" name is not the real name it is just for discussion purposes. The name "myserver.myschool.edu" has other SRV records associated with it. For example:
$nslookup > set type=SRV
_kerberos._udp.myserver.myschool.edu
_kerberos._udp.net.isc.upenn.edu service = 0 100 88 trixie.myserver.myschool.edu _kerberos._udp.net.isc.upenn.edu service = 0 100 88 pops.myserver.myschool.edu
In the past month we upgraded to this release of SER and noticed a problem when users call forward their extension to an off campus PSTN number.
If the Call Forward Always flag is set to Y then the R-URI is re-written to be a new user portion with our SIP domain name appended as the hostname. In some ngrep traces I'm seeing our proxy trying to send the forwarded call to a next hop address of "pops.myserver.myschool.edu" as shown above. The problem is pops is not a SIP server.
Use ngrep to watch also the DNS lookups (ngrep port 5060 or port 53) and verify what ser really looks up in DNS. The kerberos SRV entries must not interfere, but they are in a different domain, thus when looking up _sip._udp.... the kerberos entries should never be seen by ser.
OK. I'll add this check. I agree the kerberos entries shouldn't interfere but I cannot explain why SER would think the domain controller host would be the next hop.
_Steve
regards klaus
The only connection between our SIP environment and the host pops is the domain name. This suggests an issue with SRV resolution but I do not see the problem in my traces. Does anyone have any thoughts on this issue?
Thanks,Steve
Steve Blair wrote:
Klaus Darilion wrote:
Use ngrep to watch also the DNS lookups (ngrep port 5060 or port 53) and verify what ser really looks up in DNS. The kerberos SRV entries must not interfere, but they are in a different domain, thus when looking up _sip._udp.... the kerberos entries should never be seen by ser.
OK. I'll add this check. I agree the kerberos entries shouldn't interfere but I cannot explain why SER would think the domain controller host would be the next hop.
maybe someone fumbled in DNS? :-)
regards klaus
Klaus Darilion wrote:
Steve Blair wrote:
Klaus Darilion wrote:
Use ngrep to watch also the DNS lookups (ngrep port 5060 or port 53) and verify what ser really looks up in DNS. The kerberos SRV entries must not interfere, but they are in a different domain, thus when looking up _sip._udp.... the kerberos entries should never be seen by ser.
OK. I'll add this check. I agree the kerberos entries shouldn't interfere but I cannot explain why SER would think the domain controller host would be the next hop.
maybe someone fumbled in DNS? :-)
Possible. I have a test scheduled today with our DNS "person".During that session they will enable logging, it is usually off. Hopefully the logging will explain what is happening.
Thanks,Steve
regards klaus
Steve Blair wrote:
Klaus Darilion wrote:
Steve Blair wrote:
Klaus Darilion wrote:
Use ngrep to watch also the DNS lookups (ngrep port 5060 or port 53) and verify what ser really looks up in DNS. The kerberos SRV entries must not interfere, but they are in a different domain, thus when looking up _sip._udp.... the kerberos entries should never be seen by ser.
OK. I'll add this check. I agree the kerberos entries shouldn't interfere but I cannot explain why SER would think the domain controller host would be the next hop.
maybe someone fumbled in DNS? :-)
Possible. I have a test scheduled today with our DNS "person".During that session they will enable logging, it is usually off. Hopefully the logging will explain what is happening.
Why so complicated? Just use grep and dig.
regards klaus
Klaus Darilion wrote:
Steve Blair wrote:
Klaus Darilion wrote:
Steve Blair wrote:
Klaus Darilion wrote:
Use ngrep to watch also the DNS lookups (ngrep port 5060 or port 53) and verify what ser really looks up in DNS. The kerberos SRV entries must not interfere, but they are in a different domain, thus when looking up _sip._udp.... the kerberos entries should never be seen by ser.
OK. I'll add this check. I agree the kerberos entries shouldn't interfere but I cannot explain why SER would think the domain controller host would be the next hop.
maybe someone fumbled in DNS? :-)
Possible. I have a test scheduled today with our DNS "person".During that session they will enable logging, it is usually off. Hopefully the logging will explain what is happening.
Why so complicated? Just use grep and dig.
Sometimes you need to confirm things :-)
Anyhow I did the tcpdump, I saw the request from SER and the response from our DNS server. SER is asking for the "A" record instead of the "SRV" record. By this I mean SER is performing the equivalent of "dig myserver.myschool.edu A". This is not what we want and not what happened in past release of SER. What I want is "dig _sip._udp.myserver.myschool.edu SRV". Any thoughts on what might be happening?
_Steve
regards klaus
Steve Blair wrote:
Klaus Darilion wrote:
Steve Blair wrote:
Klaus Darilion wrote:
Steve Blair wrote:
Klaus Darilion wrote:
Use ngrep to watch also the DNS lookups (ngrep port 5060 or port 53) and verify what ser really looks up in DNS. The kerberos SRV entries must not interfere, but they are in a different domain, thus when looking up _sip._udp.... the kerberos entries should never be seen by ser.
OK. I'll add this check. I agree the kerberos entries shouldn't interfere but I cannot explain why SER would think the domain controller host would be the next hop.
maybe someone fumbled in DNS? :-)
Possible. I have a test scheduled today with our DNS "person".During that session they will enable logging, it is usually off. Hopefully the logging will explain what is happening.
Why so complicated? Just use grep and dig.
Sometimes you need to confirm things :-)
Anyhow I did the tcpdump, I saw the request from SER and the response from our DNS server. SER is asking for the "A" record instead of the "SRV" record. By this I mean SER is performing the equivalent of "dig myserver.myschool.edu A". This is not what we want and not what happened in past release of SER. What I want is "dig _sip._udp.myserver.myschool.edu SRV". Any thoughts on what might be happening?
ser bybasses SRV lookups if there is a port number present in the r-URI (RFC3263). Make sure there is no port in the r-URI.
regards klaus
Klaus Darilion wrote:
Anyhow I did the tcpdump, I saw the request from SER and the response from our DNS server. SER is asking for the "A" record instead of the "SRV" record. By this I mean SER is performing the equivalent of "dig myserver.myschool.edu A". This is not what we want and not what happened in past release of SER. What I want is "dig _sip._udp.myserver.myschool.edu SRV". Any thoughts on what might be happening?
ser bybasses SRV lookups if there is a port number present in the r-URI (RFC3263). Make sure there is no port in the r-URI.
Is this a change/refinement with SER 0.9.7-pre3? Our previous configuration file, which we used with SER 0.9.6 uses the same rewrite command as the current configuration file. Both versions specify a port number but the previous config file worked with SER 0.9.6.
-Steve
regards klaus
Steve Blair wrote:
Klaus Darilion wrote:
Anyhow I did the tcpdump, I saw the request from SER and the response from our DNS server. SER is asking for the "A" record instead of the "SRV" record. By this I mean SER is performing the equivalent of "dig myserver.myschool.edu A". This is not what we want and not what happened in past release of SER. What I want is "dig _sip._udp.myserver.myschool.edu SRV". Any thoughts on what might be happening?
ser bybasses SRV lookups if there is a port number present in the r-URI (RFC3263). Make sure there is no port in the r-URI.
Is this a change/refinement with SER 0.9.7-pre3? Our previous configuration file, which we used with SER 0.9.6 uses the same rewrite command as the current configuration file. Both versions specify a port number but the previous config file worked with SER 0.9.6.
Hi Steve! I have no glue if the behaviour has changed, but if there is a port specified then ser 0.9.7-pre3 behaves correct. Remove the port and it should work fine.
regards klaus
-
Klaus Darilion -
Steve Blair