[Serusers] Can SER 2.0.0-rc1 pstn.cfg file actually work with BYE from PSTN?

Mon Sep 28 20:59:41 CEST 2009

I'm not really sure I understand your logic, but anyway... ;-)

Here's what I see:
 Caller as available at sip:3796661000 at 66.77.88.99 (initial contact in 
INVITE). Then the INVITE sent on to the GW uses another contact 
sip:3796661000 at 206.33.44.55:5060 (changed by SER?!). The GW's BYE is 
correctly using the modified contact (sip:3796661000 at 206.33.44.55:5060) 
as ruri. SER does loose routing, sees only one Route (myself), strips it 
and uses ruri to forward to itself. Now the BYE is not loose routed and 
SER tries to look up, does not find a local match and (I assume) decides 
its for the PSTN.

A few questions:
- Why does the Contact get changed?
- Are you doing double record-routing or is the double route due to SER 
forwarding to itself as explained above? (I seem to remember you had an 
issue on that earlier)

Other things that may or may not be relevant:
- What is your alias/listen section in your ser.cfg?
- How do you test for a URI being local? Do you use the domain module? 
uri==myself?

g-)

Frank Durda IV wrote:
> Greger Viken Teigre wrote:
>> Ok, Frank. You have told me that you don't want me to respond,
>
> Actually I was hoping to nudge people who knew the answer to actually
> provide the answer.  The last dozen or so questions asked here over
> the past several months have pretty-much received no useful answers,
> although the one where I provided a code fix saw the change quietly
> introduced into a new release of that piece of software with no comment.
>
> It seems that when I gave lots of detail, someone was bound to say I
> needed to simplify the question because they didn't have time to
> read it all, but if I reduced it to an A, B, C case, someone would
> say they needed every SIP message and the .cfg file.
> Can't seem to win, so I elected to provide what was requested.  :-)
>
> Anyway, here are the pieces you asked about.  If you need more,
> just ask. I realize how much you are getting paid for your assistance
> (nearly some).  
> If the PSTN switch really is making a mistake in this scenario
> (the "BYE" seems okay and because of the presence of the Record-Route
> it is only sent to the Record-Route address), please indicate
> where it violates RFC so I can start the long process of getting
> them to investigate and with luck I would have a fix in a year...  :-(
>
>
> The original INVITE, as sent from a test Asterisk box.
> IP addresses and phone numbers have been globally changed to
> protect the innocent.
>
> Our players in this sample:
> 66.77.88.99 Asterisk box originating the call
> 206.33.44.55 SER box in the middle
> 10.100.20.30 PSTN gateway (SIP is really handled at a
> 10.x.x.x address, all others public)
> The SIP Phone placing the call is 3796661000
> Someone out on the PSTN is the phone 9615551212 that
> answers the call and goes on hook first, so the
> PSTN switch receives a SS7 REL message and causes
> it to emit the BYE back to SER.
>
>
> U 2009/09/28 03:47:10.060467 66.77.88.99:5060 -> 206.33.44.55:5060
> INVITE sip:9615551212 at 206.33.44.55 SIP/2.0
> Via: SIP/2.0/UDP 66.77.88.99:5060;branch=z9hG4bK2a748d20;rport
> From: "TEST PHONE 1000" <sip:3796661000 at 66.77.88.99>;tag=as6e0e68d0
> To: <sip:9615551212 at 206.33.44.55>
> Contact: <sip:3796661000 at 66.77.88.99>
> Call-ID: 106cc02230e60e47223b9e643eee9f37 at 66.77.88.99
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX
> Max-Forwards: 70
> Date: Mon, 28 Sep 2009 03:47:10 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> Supported: replaces
> Content-Type: application/sdp
> Content-Length: 415
>
> v=0
> o=root 45142 45142 IN IP4 66.77.88.99
> s=session
> c=IN IP4 66.77.88.99
> t=0 0
> m=audio 10918 RTP/AVP 0 3 8 112 5 10 7 97 111
> a=rtpmap:0 PCMU/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:112 AAL2-G726-32/8000
> a=rtpmap:5 DVI4/8000
> a=rtpmap:10 L16/8000
> a=rtpmap:7 LPC/8000
> a=rtpmap:97 iLBC/8000
> a=fmtp:97 mode=30
> a=rtpmap:111 G726-32/8000
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
>
> Here is the INVITE that SER sent on to the PSTN gateway:
>
> U 2009/09/28 03:47:10.061905 206.33.44.55:5060 -> 10.100.20.30:5060
> INVITE sip:9615551212 at 10.100.20.30 SIP/2.0
> Record-Route: <sip:206.33.44.55;ftag=as6e0e68d0;lr=on>
> Via: SIP/2.0/UDP 
> 206.33.44.55;branch=z9hG4bKd151.5aa15121b87cf2215ad100fd89896056.0
> Via: SIP/2.0/UDP 66.77.88.99:5060;branch=z9hG4bK2a748d20;rport=5060
> From: "TEST PHONE 1000" <sip:3796661000 at 66.77.88.99>;tag=as6e0e68d0
> To: <sip:9615551212 at 206.33.44.55>
> Contact: <sip:3796661000 at 206.33.44.55:5060>
> Call-ID: 106cc02230e60e47223b9e643eee9f37 at 66.77.88.99
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX
> Max-Forwards: 16
> Date: Mon, 28 Sep 2009 03:47:10 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> Supported: replaces
> Content-Type: application/sdp
> Content-Length: 435
>
> v=0
> o=root 45142 45142 IN IP4 66.77.88.99
> s=session
> c=IN IP4 66.77.88.99
> t=0 0
> m=audio 31768 RTP/AVP 0 3 8 112 5 10 7 97 111
> a=rtpmap:0 PCMU/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:112 AAL2-G726-32/8000
> a=rtpmap:5 DVI4/8000
> a=rtpmap:10 L16/8000
> a=rtpmap:7 LPC/8000
> a=rtpmap:97 iLBC/8000
> a=fmtp:97 mode=30
> a=rtpmap:111 G726-32/8000
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
> a=nortpproxy:yes
>
>
> Now, here is the BYE coming from the PSTN switch to SER,
> which it would be really nice if SER sent on to the calling
> asterisk box:
>
>
> U 2009/09/28 03:47:27.619185 10.100.20.30:5060 -> 206.33.44.55:5060
> BYE sip:3796661000 at 206.33.44.55:5060 SIP/2.0
> Via: SIP/2.0/UDP 
> 10.100.20.30;branch=z9hG4bK+2403b90cbb5388c3a1fbf676690bb105+000a0283+1
> Max-Forwards: 70
> Call-ID: 106cc02230e60e47223b9e643eee9f37 at 66.77.88.99
> From: <sip:9615551212 at 206.33.44.55>;tag=000a0283+1+4906002d+2fd2af7a
> To: "TEST PHONE 1000" <sip:3796661000 at 66.77.88.99>;tag=as6e0e68d0
> CSeq: 969167137 BYE
> Route: <sip:206.33.44.55;ftag=as6e0e68d0;lr=on>
> Supported: timer
> Content-Length: 0
>
>
> and here is the BYE that SER sends right back to the PSTN
> switch, which wonders why it was sent this junk:
>
>
> U 2009/09/28 03:47:27.627511 206.33.44.55:5060 -> 10.100.20.30:5060
> BYE sip:3796661000 at 10.100.20.30:5060 SIP/2.0
> Record-Route: <sip:206.33.44.55;ftag=000a0283+1+4906002d+2fd2af7a;lr=on>
> Record-Route: <sip:206.33.44.55;ftag=000a0283+1+4906002d+2fd2af7a;lr=on>
> Via: SIP/2.0/UDP 
> 206.33.44.55;branch=z9hG4bK9f22.8367f454f9911340deec0901b216f326.0
> Via: SIP/2.0/UDP 
> 206.33.44.55;branch=z9hG4bK9f22.55530ed60f502428f904e8008519abec.0
> Via: SIP/2.0/UDP 
> 10.100.20.30;branch=z9hG4bK+2403b90cbb5388c3a1fbf676690bb105+000a0283+1
> Max-Forwards: 15
> Call-ID: 106cc02230e60e47223b9e643eee9f37 at 66.77.88.99
> From: <sip:9615551212 at 206.33.44.55>;tag=000a0283+1+4906002d+2fd2af7a
> To: "TEST PHONE 1000" <sip:3796661000 at 66.77.88.99>;tag=as6e0e68d0
> CSeq: 969167137 BYE
> Supported: timer
> Content-Length: 0
>
>
> and of course, the PSTN switch replies "Huh?":
>
>
> U 2009/09/28 03:47:27.629429 10.100.20.30:5060 -> 206.33.44.55:5060
> SIP/2.0 481 Call/Transaction Does Not Exist
> Record-Route: <sip:206.33.44.55;ftag=000a0283+1+4906002d+2fd2af7a;lr=on>
> Record-Route: <sip:206.33.44.55;ftag=000a0283+1+4906002d+2fd2af7a;lr=on>
> Via: SIP/2.0/UDP 
> 206.33.44.55;branch=z9hG4bK9f22.8367f454f9911340deec0901b216f326.0
> Via: SIP/2.0/UDP 
> 206.33.44.55;branch=z9hG4bK9f22.55530ed60f502428f904e8008519abec.0
> Via: SIP/2.0/UDP 
> 10.100.20.30;branch=z9hG4bK+2403b90cbb5388c3a1fbf676690bb105+000a0283+1
> Max-Forwards: 15
> Call-ID: 106cc02230e60e47223b9e643eee9f37 at 66.77.88.99
> From: <sip:9615551212 at 206.33.44.55>;tag=000a0283+1+4906002d+2fd2af7a
> To: "TEST PHONE 1000" <sip:3796661000 at 66.77.88.99>;tag=as6e0e68d0
> CSeq: 969167137 BYE
> Supported: timer
> Content-Length: 0
>
>
> and SER responds right back with "Double-Huh?"
>
>
> U 2009/09/28 03:47:27.629558 206.33.44.55:5060 -> 10.100.20.30:5060
> SIP/2.0 481 Call/Transaction Does Not Exist
> Record-Route: <sip:206.33.44.55;ftag=000a0283+1+4906002d+2fd2af7a;lr=on>
> Record-Route: <sip:206.33.44.55;ftag=000a0283+1+4906002d+2fd2af7a;lr=on>
> Via: SIP/2.0/UDP 
> 10.100.20.30;branch=z9hG4bK+2403b90cbb5388c3a1fbf676690bb105+000a0283+1
> Max-Forwards: 15
> Call-ID: 106cc02230e60e47223b9e643eee9f37 at 66.77.88.99
> From: <sip:9615551212 at 206.33.44.55>;tag=000a0283+1+4906002d+2fd2af7a
> To: "TEST PHONE 1000" <sip:3796661000 at 66.77.88.99>;tag=as6e0e68d0
> CSeq: 969167137 BYE
> Supported: timer
> Content-Length: 0
>
> and so on...
>
>
> Thanks for looking!
>