[Serusers] SER and re-INVITE (ACK for 488 msg)

Fri Oct 8 11:03:05 CEST 2004

As described in RFC 3261, section 12.2 Requests within a Dialog :

"Requests within a dialog MAY contain Record-Route and Contact header 
fields. However, these requests do not cause the dialog's route set to 
be modified, although they may modify the remote target URI."

As the GW uses for the re-INVITE the route set learned via original 
INVITE (there are 2 Route hdr in your re-INVITE), SER follows the same 
principal and when generating the ACK, instead of using the RR from 
re_INVITE reply, it uses also the Route set from RE-INVITE.

Anyhow, as you can see, the 488 reply doen't mirror at all the RR set, 
since the .18 device knows that is a reply for a re-INVITE and the ROUTE 
set is already established.

bogdan

Chuck Ramirez wrote:

>Hello guys,
>
>I'm trying to understand what is happening with SER
>and re-INVITEs (for T.38 fax). 
>
>I have the follwing scenario:
>
>
>ATA -> Session Border(NAT) -> SER -> Cisco Gateway
>
>
>The ATA connects to the Cisco gateway for a voice call
>and when the gateway receives a fax tone is starts a
>re-INVITE to try to negotiate T38 parameters. Then ATA
>responds with 488 Not Supported Here and SER sends a
>ACK back to the ATA before sending 488 to the gateway.
>
>In this ACK it seems that SER is adding an extra route
>header as the INVITE that was sent to the ATA had only
>one route header. Why SER is adding two route headers?
>
>
>I'm attaching ngrep logs to this mail (with some
>further comments), where:
>
>The IP 10.0.0.19 is the Proxy
>The IP 10.0.0.67 is the gateway
>The IP 10.0.0.18 is the Session Border (NAT)
>
>Thanks in advance,
>
>Chuck.
>
>
>		
>_______________________________
>Do you Yahoo!?
>Declare Yourself - Register online to vote today!
>http://vote.yahoo.com
>
>------------------------------------------------------------------------
>
>#
>U 10.0.0.67:50549 -> 10.0.0.19:5060
>  INVITE sip:1234 at 10.0.0.19:5060;ftag=2482904200;lr SIP/2.0..Via: SIP/2.0/UDP  10.0.0.67:5060..Fro
>  m: <sip:1234 at proxy.com;user=phone>;tag=48235ADC-1DB8..To: <sip:55519 at proxy.com;user=phone>;
>  tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12 GMT..Call-ID: 137792672 at 10.0.0.35..Route:
>   <sip:1234 at 10.0.0.18:5071>, <sip:55519 at 10.0.0.18:5071;user=phone>..Supported: timer,100rel..Min-
>  SE:  1800..Cisco-Guid: 1053952464-397283801-2441193380-2221309272..User-Agent: Cisco-SIPGateway/IOS-12.x..
>  Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO..CSeq: 101 INVITE..
>  Max-Forwards: 6..Remote-Party-ID: <sip:55519 at 10.0.0.67>;party=calling;screen=no;privacy=off..Timestam
>  p: 1097163732..Contact: <sip:747%23555133280636 at 10.0.0.67:5060>..Expires: 180..Allow-Events: telephon
>  e-event..Content-Type: application/sdp..Content-Length: 402....v=0..o=CiscoSystemsSIP-GW-UserAgent 8783 11
>  68 IN IP4 10.0.0.67..s=SIP Call..c=IN IP4 10.0.0.67..t=0 0..m=image 18742 udptl t38..c=IN IP4 20
>  0.175.202.67..a=T38FaxVersion:0..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0
>  ..a=T38FaxTranscodingJBIG:0..a=T38FaxRateManagement:transferredTCF..a=T38FaxMaxBuffer:200..a=T38FaxMaxData
>  gram:72..a=T38FaxUdpEC:t38UDPRedundancy..
>#
>U 10.0.0.19:5060 -> 10.0.0.67:5060
>  SIP/2.0 100 Trying..Via: SIP/2.0/UDP  10.0.0.67:5060..From: <sip:1234 at proxy.com;user=
>  phone>;tag=48235ADC-1DB8..To: <sip:55519 at proxy.com;user=phone>;tag=2482904200..Call-ID: 13
>  7792672 at 10.0.0.35..CSeq: 101 INVITE..Server:  Sip Router..Content-Length: 0....
>#
>
>====The INVITE sent to the ATA has only one route header======
>
>
>U 10.0.0.19:5060 -> 10.0.0.18:5071
>  INVITE sip:1234 at 10.0.0.18:5071 SIP/2.0..Record-Route: <sip:1234 at 10.0.0.19;ftag=48235ADC-1DB8;lr>
>  ..Via: SIP/2.0/UDP 10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..Via: SIP/2.0/UDP  10.0.0.67:5060..Fr
>  om: <sip:1234 at proxy.com;user=phone>;tag=48235ADC-1DB8..To: <sip:55519 at proxy.com;user=phone>;
>  tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12 GMT..Call-ID: 137792672 at 10.0.0.35..Route
>  : <sip:55519 at 10.0.0.18:5071;user=phone>..Supported: timer,100rel..Min-SE:  1800..Cisco-Guid: 10539524
>  64-397283801-2441193380-2221309272..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CA
>  NCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO..CSeq: 101 INVITE..Max-Forwards: 5..Remote-Party-I
>  D: <sip:55519 at 10.0.0.67>;party=calling;screen=no;privacy=off..Timestamp: 1097163732..Contact: <sip:74
>  7%23555133280636 at 10.0.0.67:5060>..Expires: 180..Allow-Events: telephone-event..Content-Type: applicat
>  ion/sdp..Content-Length: 402....v=0..o=CiscoSystemsSIP-GW-UserAgent 8783 1168 IN IP4 10.0.0.67..s=SIP
>   Call..c=IN IP4 10.0.0.67..t=0 0..m=image 18742 udptl t38..c=IN IP4 10.0.0.67..a=T38FaxVersion:0
>  ..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0..a=T38FaxTranscodingJBIG:0..a=
>  T38FaxRateManagement:transferredTCF..a=T38FaxMaxBuffer:200..a=T38FaxMaxDatagram:72..a=T38FaxUdpEC:t38UDPRe
>  dundancy..
>#
>U 10.0.0.18:5071 -> 10.0.0.19:5060
>  SIP/2.0 488 Not Acceptable Here..Via: SIP/2.0/UDP 10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..Via: SIP/2
>  .0/UDP 10.0.0.67:5060..From: <sip:1234 at proxy.com;user=phone>;tag=48235ADC-1DB8..To: <
>  sip:55519 at proxy.com;user=phone>;tag=2482904200..Call-ID: 137792672 at 10.0.0.35..CSeq: 101 IN
>  VITE..timestamp: 1097163732..server: Cisco ATA 186  v3.1.0 atasip (040211A)..warning: Media type not avail
>  able..Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER..Content-Length: 0....
>#
>
>===========The ACK sent to ATA has two route headers, and the top route header is the same as the R-Uri.
>===========Is this correct?
>
>
>
>U 10.0.0.19:5060 -> 10.0.0.18:5071
>  ACK sip:1234 at 10.0.0.18:5071 SIP/2.0..Via: SIP/2.0/UDP 10.0.0.19;branch=z9hG4bK2c09.8631afe3.0..F
>  rom: <sip:1234 at proxy.com;user=phone>;tag=48235ADC-1DB8..Call-ID: 137792672 at 10.0.0.35..To:
>  <sip:55519 at proxy.com;user=phone>;tag=2482904200..CSeq: 101 ACK..Route: <sip:1234 at 10.0.0.18:5071>, 
>  <sip:55519 at 10.0.0.18:5071;user=phone>..User-Agent:  Sip Router..Content-Length
>  : 0....
>#
>U 10.0.0.19:5060 -> 10.0.0.67:5060
>  SIP/2.0 488 Not Acceptable Here..Via: SIP/2.0/UDP 10.0.0.67:5060..From: <sip:1234 at proxy.com;user=phone>;
>  tag=48235ADC-1DB8..To: <sip:55519 at proxy.com;user=phone>;tag=2482904200.
>  .Call-ID: 137792672 at 10.0.0.35..CSeq: 101 INVITE..timestamp: 1097163732..server: Cisco ATA 186  v3.1.0 atas
>  ip (040211A)..warning: Media type not available..Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER,
>  REGISTER..Content-Length: 0....
>#
>
>
>
>===========Supposing that this ACK was not absorved by the proxy, what would be the behavior of loose_route()?
>===========Wouldn't loose_route change the R-URI by the topmost router and then remove it? If so, this ACK
>===========would be equal to the one previously sent by ser but it would have only one route header. Am I missing
>===========something?
>
>
>
>
>
>U 10.0.0.67:50549 -> 10.0.0.19:5060
>  ACK sip:1234 at 10.0.0.19:5060;ftag=2482904200;lr SIP/2.0..Via: SIP/2.0/UDP  10.0.0.67:5060..From:
>  <sip:1234 at proxy.com;user=phone>;tag=48235ADC-1DB8..To: <sip:55519 at proxy.com;user=phone>;
>  tag=2482904200..Date: Thu, 07 Oct 2004 15:42:12 GMT..Call-ID: 137792672 at 10.0.0.35..Route: <s
>  ip:1234 at 10.0.0.18:5071>, <sip:55519 at 10.0.0.18:5071;user=phone>..Max-Forwards: 6..Content-Length:
>   0..CSeq: 101 ACK....
>#
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>  
>