22 Aug
2009
22 Aug
'09
6:50 p.m.
hi!
i'm the developer of a sip app that happens to be connecting to a sip
server that's using SER.
i'm having troublewith the way SER handles incoming calls to my
stun-enabled ua (which is placed behind a router)
I have two clients running on the same machine. one is my app, the other
is Gizmo5.
when i make an outgoing call from my app to the user i'm logged in with
in Gizmo5, everything works.
but when i call my app from the Gizmo5 app, sniffing the network
traffic with wireshark, the only thing i see happening is the sip server
sending a 100 Giving a try to the calling ua.
The reason i'm posting this here, is that i know it's not a bug with my
app, since everything works fine when i don't use stun.
(note that i don't have direct access to ser's configuration)
this is my app's REGISTER request (note that it has a *public ip*):
REGISTER sip:proxy01.sipphone.com SIP/2.0
Via: SIP/2.0/UDP 93.148.135.54:5060;rport;branch=z9hG4bK70207
Max-Forwards: 70
To: <sip:asymmetric@proxy01.sipphone.com>
From: <sip:asymmetric@proxy01.sipphone.com>;tag=z9hG4bK57274073
Call-ID: 557402852938(a)93.148.135.54
CSeq: 2 REGISTER
Contact: <sip:asymmetric@93.148.135.54:5060;transport=udp>
Expires: 3600
User-Agent: mjsip stack 1.6
Authorization: Digest username="asymmetric",
realm="proxy01.sipphone.com", nonce="xxx",
uri="sip:proxy01.sipphone.com", algorithm=md5, response="yyy"
Content-Length: 0
and the response:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 93.148.135.54:5060;rport=12810;branch=z9hG4bK70207
To:
<sip:asymmetric@proxy01.sipphone.com>;tag=92390300a369f0d75803e369c733575e.50aa
From: <sip:asymmetric@proxy01.sipphone.com>;tag=z9hG4bK57274073
Call-ID: 557402852938(a)93.148.135.54
CSeq: 2 REGISTER
Contact: <sip:asymmetric@93.148.135.54:5060;transport=udp>;expires=3600
Content-Length: 0
Gizmo5's app REGISTER request:
REGISTER sip:proxy01.sipphone.com SIP/2.0
Via: SIP/2.0/UDP
192.168.1.100:64064;branch=z9hG4bK-d87543-bbc1e2712d417352-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:17474492586@93.148.135.54:10251>
To: <sip:17474492586@proxy01.sipphone.com>
From: <sip:17474492586@proxy01.sipphone.com>;tag=f43be43c
Call-ID: b1b4a060512d4b0c1250955005@YXN5bW1ldHJpYy5sb2NhbA..
CSeq: 2 REGISTER
Expires: 1800
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
User-Agent: MacGizmo/2.0.02 (Gizmo-s2n1)
Authorization: Digest
username="17474492586",realm="proxy01.sipphone.com",nonce="xxx",uri="sip:proxy01.sipphone.com",response="yyy",algorithm=MD5
Content-Length: 0
and response:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.1.100:64064;branch=z9hG4bK-d87543-bbc1e2712d417352-1--d87543-;rport=10251;received=93.148.135.54
To:
<sip:17474492586@proxy01.sipphone.com>;tag=92390300a369f0d75803e369c733575e.c70f
From: <sip:17474492586@proxy01.sipphone.com>;tag=f43be43c
Call-ID: b1b4a060512d4b0c1250955005@YXN5bW1ldHJpYy5sb2NhbA..
CSeq: 2 REGISTER
P-Behind-NAT: Yes
Contact: <sip:17474492586@93.148.135.54:10251>;expires=1800
Content-Length: 0
in the second case, the client gets the P-Behind-NAT flag set to Yes,
and for a good reason.
But then why is this all i get when trying to call the first ua? :
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP
192.168.1.100:64064;branch=z9hG4bK-d87543-7fb07a028db5c137-1--d87543-;rport=10251;received=93.148.135.54
To: <sip:asymmetric@proxy01.sipphone.com>
From: <sip:17474492586@proxy01.sipphone.com>;tag=bc135372
Call-ID: 88d41c746d51146e1250955219@YXN5bW1ldHJpYy5sb2NhbA..
CSeq: 1 INVITE
P-Behind-NAT: Yes
Content-Length: 0
whereas the inverse works:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 198.65.166.131;branch=z9hG4bKf3b1.bc014575.0
Via: SIP/2.0/UDP 93.148.135.54:5060;rport=13171;branch=z9hG4bK82654
Record-Route: <sip:198.65.166.131;lr;ftag=z9hG4bK90319798>
Contact: <sip:17474492586@proxy01.sipphone.com>
To: <sip:17474492586@proxy01.sipphone.com>;tag=6ae0e759
From:
"asymmetric"<sip:asymmetric@proxy01.sipphone.com>;tag=z9hG4bK90319798
Call-ID: 593542951976(a)93.148.135.54
CSeq: 1 INVITE
User-Agent: MacGizmo/2.0.02 (Gizmo-s2n1)
Content-Length: 0
CQBM: 244
--
thanks a lot!
asymmetric
22 Aug
22 Aug
7:56 p.m.
lorenzo wrote:
i'm the developer of a sip app that happens to be connecting to a sip
server that's using SER.
i'm having troublewith the way SER handles incoming calls to my
stun-enabled ua (which is placed behind a router)
Unfortunately, there is no single way SER is handling these things. This
depends to a great deal on the config, NAT handling in particular.
This here
SIP/2.0 100 Giving a try
doesn't look like stock SER either.
I am afraid you will have to take this up, presumably, sipphone.com.
Regards,
Martin
24 Aug
24 Aug
10:36 a.m.
Am 22.08.09 17:50, schrieb lorenzo:
hi!
i'm the developer of a sip app that happens to be connecting to a sip
server that's using SER.
i'm having troublewith the way SER handles incoming calls to my
stun-enabled ua (which is placed behind a router)
I have two clients running on the same machine. one is my app, the other
is Gizmo5.
when i make an outgoing call from my app to the user i'm logged in with
in Gizmo5, everything works.
but when i call my app from the Gizmo5 app, sniffing the network
traffic with wireshark, the only thing i see happening is the sip server
sending a 100 Giving a try to the calling ua.
The reason i'm posting this here, is that i know it's not a bug with my
app, since everything works fine when i don't use stun.
Just because your app works without stun does not mean it is bug, or?!
(note that i don't have direct access to ser's
configuration)
this is my app's REGISTER request (note that it has a *public ip*):
Sorry, but if it runs on a public IP, why do you use STUN at all?
Or are you just referring with "have" to the fact that your app "has"
successfully determined the public IP of its router?
The major difference in the messages below which I can spot is the IP
address in the Via header. Gizmo puts its private IP in the Via header,
where yours puts the public IP in the Via header.
SER's NAT support has functions to check the Via header for indications
of a NAT. It might be that your public IP mis-leads these check to
believe that your app does not need NAT traversal support (which it
obviously really does not need if it runs on a public IP anyway). But as
Martin wrote: we do not have access to sipphone's SER config, so we
can't tell you which NAT checks they perform.
My guess is, that your app is the classic example of the wrong usage of
STUN. Your REGISTER request does not contain a single indication any
more that your app is actually running behind a NAT. So how should SER
be able to identify you as being behind a NAT?
(That you are using the rport parameter is not enough, because as your
username already suggests: this is just an indication that you are doing
asymmetric SIP signaling (which is deprecated and totally broken if you
are behind a NAT anyway).)
Cheers
Nils
REGISTER sip:proxy01.sipphone.com SIP/2.0
Via: SIP/2.0/UDP 93.148.135.54:5060;rport;branch=z9hG4bK70207
Max-Forwards: 70
To:<sip:asymmetric@proxy01.sipphone.com>
From:<sip:asymmetric@proxy01.sipphone.com>;tag=z9hG4bK57274073
Call-ID: 557402852938(a)93.148.135.54
CSeq: 2 REGISTER
Contact:<sip:asymmetric@93.148.135.54:5060;transport=udp>
Expires: 3600
User-Agent: mjsip stack 1.6
Authorization: Digest username="asymmetric",
realm="proxy01.sipphone.com", nonce="xxx",
uri="sip:proxy01.sipphone.com", algorithm=md5, response="yyy"
Content-Length: 0
and the response:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 93.148.135.54:5060;rport=12810;branch=z9hG4bK70207
To:
<sip:asymmetric@proxy01.sipphone.com>;tag=92390300a369f0d75803e369c733575e.50aa
From:<sip:asymmetric@proxy01.sipphone.com>;tag=z9hG4bK57274073
Call-ID: 557402852938(a)93.148.135.54
CSeq: 2 REGISTER
Contact:<sip:asymmetric@93.148.135.54:5060;transport=udp>;expires=3600
Content-Length: 0
Gizmo5's app REGISTER request:
REGISTER sip:proxy01.sipphone.com SIP/2.0
Via: SIP/2.0/UDP
192.168.1.100:64064;branch=z9hG4bK-d87543-bbc1e2712d417352-1--d87543-;rport
Max-Forwards: 70
Contact:<sip:17474492586@93.148.135.54:10251>
To:<sip:17474492586@proxy01.sipphone.com>
From:<sip:17474492586@proxy01.sipphone.com>;tag=f43be43c
Call-ID: b1b4a060512d4b0c1250955005@YXN5bW1ldHJpYy5sb2NhbA..
CSeq: 2 REGISTER
Expires: 1800
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
User-Agent: MacGizmo/2.0.02 (Gizmo-s2n1)
Authorization: Digest
username="17474492586",realm="proxy01.sipphone.com",nonce="xxx",uri="sip:proxy01.sipphone.com",response="yyy",algorithm=MD5
Content-Length: 0
and response:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.1.100:64064;branch=z9hG4bK-d87543-bbc1e2712d417352-1--d87543-;rport=10251;received=93.148.135.54
To:
<sip:17474492586@proxy01.sipphone.com>;tag=92390300a369f0d75803e369c733575e.c70f
From:<sip:17474492586@proxy01.sipphone.com>;tag=f43be43c
Call-ID: b1b4a060512d4b0c1250955005@YXN5bW1ldHJpYy5sb2NhbA..
CSeq: 2 REGISTER
P-Behind-NAT: Yes
Contact:<sip:17474492586@93.148.135.54:10251>;expires=1800
Content-Length: 0
in the second case, the client gets the P-Behind-NAT flag set to Yes,
and for a good reason.
But then why is this all i get when trying to call the first ua? :
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP
192.168.1.100:64064;branch=z9hG4bK-d87543-7fb07a028db5c137-1--d87543-;rport=10251;received=93.148.135.54
To:<sip:asymmetric@proxy01.sipphone.com>
From:<sip:17474492586@proxy01.sipphone.com>;tag=bc135372
Call-ID: 88d41c746d51146e1250955219@YXN5bW1ldHJpYy5sb2NhbA..
CSeq: 1 INVITE
P-Behind-NAT: Yes
Content-Length: 0
whereas the inverse works:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 198.65.166.131;branch=z9hG4bKf3b1.bc014575.0
Via: SIP/2.0/UDP 93.148.135.54:5060;rport=13171;branch=z9hG4bK82654
Record-Route:<sip:198.65.166.131;lr;ftag=z9hG4bK90319798>
Contact:<sip:17474492586@proxy01.sipphone.com>
To:<sip:17474492586@proxy01.sipphone.com>;tag=6ae0e759
From:
"asymmetric"<sip:asymmetric@proxy01.sipphone.com>;tag=z9hG4bK90319798
Call-ID: 593542951976(a)93.148.135.54
CSeq: 1 INVITE
User-Agent: MacGizmo/2.0.02 (Gizmo-s2n1)
Content-Length: 0
CQBM: 244
25 Aug
25 Aug
7:30 p.m.
Nils Ohlmeier wrote:
Am 22.08.09 17:50, schrieb lorenzo:
Sorry, but if it runs on a public IP, why do you use STUN at all?
Or are you just referring with "have" to the fact that your app
"has"
successfully determined the public IP of its router?
yes, what i was trying to say here is that the app correctly
*discovered* the router's public ip through a query to a stun server.
The major difference in the messages below which I can
spot is the IP
address in the Via header. Gizmo puts its private IP in the Via header,
where yours puts the public IP in the Via header.
SER's NAT support has functions to check the Via header for indications
of a NAT. It might be that your public IP mis-leads these check to
believe that your app does not need NAT traversal support (which it
obviously really does not need if it runs on a public IP anyway). But as
Martin wrote: we do not have access to sipphone's SER config, so we
can't tell you which NAT checks they perform.
My guess is, that your app is the classic example of the wrong usage of
STUN. Your REGISTER request does not contain a single indication any
more that your app is actually running behind a NAT. So how should SER
be able to identify you as being behind a NAT?
my understanding of the whole nat/sip issue was that, once i forge my
REGISTER request with a public ip, then the server need not know the uac
is actually residing in a private network. thus, no special actions need
to be taken by the server, as it can simply send packets to my router's
public ip, and the router will route the packets back to the correct
host. as far as ports go, i thought rport solved the issue.
if that's the case, then SER shouldn't even need to know i'm behind a NAT.
am i correct?
one difference i see is that the response to my app's REGISTER request
(rightfully) has no "received" parameter in the VIA field - since the IP
packet's source address matches the "sent-by" parameter - but has an
rport parameter.
could that be the cause of the problem?
(That you are using the rport parameter is not enough,
because as your
username already suggests: this is just an indication that you are doing
asymmetric SIP signaling (which is deprecated and totally broken if you
are behind a NAT anyway).)
my username has nothing to do with sip :)
excuse my ignorance, but what exactly is asymmetric SIP signaling?
Cheers
Nils
thanks a lot for your interest,
asymmetric
5568
days inactive
5571
days old
3 comments
3 participants
participants (3)
-
lorenzo -
Martin Hoffmann -
Nils Ohlmeier