[Serusers] ACK not loose_routed
Cesc
cesc.santa at gmail.com
Thu Oct 12 17:58:49 CEST 2006
Hi,
The external.proxy (not ser) rewrites the contact, as a way to be a
b2bua in terms of signalling: 10.111.0.20 is the external.proxy ...
10.111.0.50 is my.ser.proxy.
In terms of ACK processing, no doubt ser does its best ... it is just
the external.proxy not processing correctly the record-route, but this
shall be fixed soon ...
Meanwhile, i modify my config so i detect this kind of ACK and simply
t_relay them, nothing else.
Thanks everyone!
Cesc
On 10/12/06, Jan Janak <jan at iptel.org> wrote:
> If you take a look at 200 OK you will notice that the value of Contact
> header is changed. The first 200 OK contains
>
> sip:6007 at 10.111.0.144:5060
>
> which I assume is correct. The second one contains:
>
> sip:10.111.0.20:5060
>
> But that (according to the dumps below) points to SER -- and that's the
> problem. Do you rewrite Contact header in SER ? If so then it should not
> point back to the SER instance.
>
> SER treats the ACK correctly -- it has no Route headers and the
> Request-URI points to SER -- hence it will process it as local message.
>
> What you need to have fixed is the IP and port in rewritten contact.
>
> Jan.
>
> Cesc wrote:
> > Tks ... i guess i will try to modify the config file so this ack
> > problem is taken care of in the most generic way i can think of ...
> >
> > What i tried and it seems it didn't work is to enter the
> > "sip:10.111.0.20:5060" as a permanent entry in the location table
> > (using serctl). This way my config, which does a lookup(location) and
> > fails and drops the ACK, it would then return true and simply t_relay
> > it ...
> >
> > as for the sjphone, i don't blame the phone. I think it does
> > reasonably good, given how bad the OK from the external.proxy gets to
> > him ...
> >
> > Cesc
> >
> > On 10/11/06, Greger V. Teigre <greger at teigre.com> wrote:
> >>
> >> Short answer: yes.
> >> Slightly longer: I have seen the same behavior. Without lr|lr=on the UA
> >> will (correctly) go over to strict routing and use contact in r-uri
> >> for the
> >> ACK. As long as only your record-route disappeared (i.e. you are the only
> >> hop in-between the UAS and UAC) this works. As your external proxy is
> >> B2BUA
> >> (at least for signalling), your fine if you relay the ACK.
> >> I'm not sure exactly when this happens and why, I seem to remember I
> >> posted
> >> something on this behavior for sjphone a while back, but I'm not
> >> capable of
> >> finding it.
> >> g-)
> >>
> >> Cesc wrote:
> >> Hello everyone!
> >>
> >> I have my system based on ser 0.9.6. Internal calls work just fine.
> >> I am now trying to interop with another system. It has a sort of
> >> asterisk functionality, but it is not asterisk, it is a private
> >> software company product.
> >>
> >> my.phone ---------> my.ser.proxy -------------> external.proxy
> >> -------------> external phone
> >> 10.111.0.119 10.111.0.50 10.111.0.20
> >> 10.111.0.144
> >>
> >> There is no firewall or nat in the way.
> >>
> >> The problem, i think, is that the external.proxy is buggy. I told
> >> that to the company, but who knows when they will fix this.
> >>
> >> * Look at the OK (message #9 and #10). My.ser.proxy record-routes all
> >> invites. The Record-route headers reach the external.phone, which
> >> copies them in the OK
> >> message, sends the OK to the external.proxy ... and when this forwards
> >> it to my.ser.proxy, they are gone! The OK reaches my.phone, but then
> >> it generates my
> >> problem: the ACK. It contains NO ROUTE headers and the r-uri is also
> >> simply pointing to the external.proxy.
> >> If the ACK had the ROUTE headers, my.ser.proxy would loose_route the
> >> message and voila!
> >> But as loose_route() returns false, my (maybe bad) config file gets
> >> confused and treats it like a "new" call ... so it lookup("location")
> >> of the ACK r-ruri fails,
> >> and the ACK is dropped.
> >> Should i modify the config file so that ACK, if not loose_route'd, are
> >> simply t_relay'd?
> >>
> >> * They also modify the contact field. The reason is because behind the
> >> external.proxy could be H323 or SIP phones, so they sort of want to be
> >> a termination as far as signalling is concerned.
> >>
> >> I attach the message flow, hope it helps ... Thanks!
> >>
> >> Cesc
> >> ________________________________
> >>
> >>
> >> No. Time Source Destination Protocol Info
> >> 1 0.000000000 10.111.0.119 10.111.0.50 SIP/SDP Request: INVITE
> >> sip:6007 at 10.111.0.20, with session description
> >> Session Initiation Protocol
> >> Request-Line: INVITE sip:6007 at 10.111.0.20 SIP/2.0
> >> Message Header
> >> Via: SIP/2.0/UDP
> >> 10.111.0.119;rport;branch=z9hG4bK0a6f0077000004b2452bb819000009f00000191e
> >> Content-Length: 337
> >> Contact: <sip:7005 at 10.111.0.119:5060>
> >> Call-ID: D95A2208-3031-44E8-862E-2877A042900D at 10.111.0.119
> >> Content-Type: application/sdp
> >> CSeq: 1 INVITE
> >> From: "7005"<sip:7005 at 10.111.0.50:5060>;tag=12083790462495
> >> Max-Forwards: 70
> >> To: <sip:6007 at 10.111.0.20>
> >> User-Agent: SJphone/1.60.289a (SJ Labs)
> >> Message body
> >> Session Description Protocol
> >> Session Description Protocol Version (v): 0
> >> Owner/Creator, Session Id (o): - 3369481881 3369481881 IN IP4
> >> 10.111.0.119
> >> Session Name (s): SJphone
> >> Connection Information (c): IN IP4 10.111.0.119
> >> Time Description, active time (t): 0 0
> >> Session Attribute (a): direction:active
> >> Media Description, name and address (m): audio 49248 RTP/AVP 3 97 98 8 0
> >> 101
> >> Media Attribute (a): rtpmap:3 GSM/8000
> >> Media Attribute (a): rtpmap:97 iLBC/8000
> >> Media Attribute (a): rtpmap:98 iLBC/8000
> >> Media Attribute (a): fmtp:98 mode=20
> >> Media Attribute (a): rtpmap:8 PCMA/8000
> >> Media Attribute (a): rtpmap:0 PCMU/8000
> >> Media Attribute (a): rtpmap:101 telephone-event/8000
> >> Media Attribute (a): fmtp:101 0-11,16
> >>
> >> No. Time Source Destination Protocol Info
> >> 3 0.001209000 10.111.0.50 10.111.0.20 SIP/SDP Request: INVITE
> >> sip:6007 at 10.111.0.20:5060, with session description
> >> Session Initiation Protocol
> >> Request-Line: INVITE sip:6007 at 10.111.0.20:5060 SIP/2.0
> >> Message Header
> >> Record-Route: <sip:10.111.0.50;ftag=12083790462495;lr=on>
> >> Via: SIP/2.0/UDP 10.111.0.50;branch=z9hG4bK2eff.75fbc652.0
> >> Via: SIP/2.0/UDP
> >> 10.111.0.119;rport=5060;branch=z9hG4bK0a6f0077000004b2452bb819000009f00000191e
> >>
> >> Content-Length: 337
> >> Contact: <sip:7005 at 10.111.0.119:5060>
> >> Call-ID: D95A2208-3031-44E8-862E-2877A042900D at 10.111.0.119
> >> Content-Type: application/sdp
> >> CSeq: 1 INVITE
> >> From: "7005"<sip:7005 at 10.111.0.50:5060>;tag=12083790462495
> >> Max-Forwards: 16
> >> To: <sip:6007 at 10.111.0.20>
> >> User-Agent: SJphone/1.60.289a (SJ Labs)
> >> Message body
> >> Session Description Protocol
> >> Session Description Protocol Version (v): 0
> >> Owner/Creator, Session Id (o): - 3369481881 3369481881 IN IP4
> >> 10.111.0.119
> >> Session Name (s): SJphone
> >> Connection Information (c): IN IP4 10.111.0.119
> >> Time Description, active time (t): 0 0
> >> Session Attribute (a): direction:active
> >> Media Description, name and address (m): audio 49248 RTP/AVP 3 97 98 8 0
> >> 101
> >> Media Attribute (a): rtpmap:3 GSM/8000
> >> Media Attribute (a): rtpmap:97 iLBC/8000
> >> Media Attribute (a): rtpmap:98 iLBC/8000
> >> Media Attribute (a): fmtp:98 mode=20
> >> Media Attribute (a): rtpmap:8 PCMA/8000
> >> Media Attribute (a): rtpmap:0 PCMU/8000
> >> Media Attribute (a): rtpmap:101 telephone-event/8000
> >> Media Attribute (a): fmtp:101 0-11,16
> >>
> >> No. Time Source Destination Protocol Info
> >> 5 0.040629000 10.111.0.20 10.111.0.144 SIP/SDP Request: INVITE
> >> sip:6007 at 10.111.0.144:5060;transport=UDP, with session
> >> description
> >> Session Initiation Protocol
> >> Request-Line: INVITE
> >> sip:6007 at 10.111.0.144:5060;transport=UDP SIP/2.0
> >> Message Header
> >> Via: SIP/2.0/UDP 10.111.0.20:5060;branch=z9hG4bKm27749469
> >> Via: SIP/2.0/UDP 10.111.0.50;branch=z9hG4bK2eff.75fbc652.0
> >> Via: SIP/2.0/UDP
> >> 10.111.0.119;rport=5060;branch=z9hG4bK0a6f0077000004b2452bb819000009f00000191e
> >>
> >> RECORD-ROUTE: <sip:10.111.0.50;ftag=12083790462495;lr=on>
> >> From: "7005"<sip:7005 at 10.111.0.50:5060>;tag=12083790462495
> >> To: <sip:6007 at 10.111.0.20>
> >> Call-ID: D95A2208-3031-44E8-862E-2877A042900D at 10.111.0.119
> >> CSeq: 1 INVITE
> >> Max-Forwards: 16
> >> Contact: <sip:10.111.0.20>
> >> User-Agent: SJphone/1.60.289a (SJ Labs)
> >> Content-Type: application/sdp
> >> Content-Length: 337
> >> Message body
> >> Session Description Protocol
> >> Session Description Protocol Version (v): 0
> >> Owner/Creator, Session Id (o): - 3369481881 3369481881 IN IP4
> >> 10.111.0.119
> >> Session Name (s): SJphone
> >> Connection Information (c): IN IP4 10.111.0.119
> >> Time Description, active time (t): 0 0
> >> Session Attribute (a): direction:active
> >> Media Description, name and address (m): audio 49248 RTP/AVP 3 97 98 8 0
> >> 101
> >> Media Attribute (a): rtpmap:3 gsm/8000
> >> Media Attribute (a): rtpmap:97 ilbc/8000
> >> Media Attribute (a): rtpmap:98 ilbc/8000
> >> Media Attribute (a): fmtp:98 mode=20
> >> Media Attribute (a): rtpmap:8 pcma/8000
> >> Media Attribute (a): rtpmap:0 pcmu/8000
> >> Media Attribute (a): rtpmap:101 telephone-event/8000
> >> Media Attribute (a): fmtp:101 0-11,16
> >>
> >> No. Time Source Destination Protocol Info
> >> 9 3.736665000 10.111.0.144 10.111.0.20 SIP/SDP Status: 200 OK, with
> >> session
> >> description
> >> Session Initiation Protocol
> >> Status-Line: SIP/2.0 200 OK
> >> Message Header
> >> Via: SIP/2.0/UDP 10.111.0.20:5060;branch=z9hG4bKm27749469
> >> Via: SIP/2.0/UDP 10.111.0.50;branch=z9hG4bK2eff.75fbc652.0
> >> Via: SIP/2.0/UDP
> >> 10.111.0.119;rport=5060;branch=z9hG4bK0a6f0077000004b2452bb819000009f00000191e
> >>
> >> Record-Route: <sip:10.111.0.50;ftag=12083790462495;lr=on>
> >> Call-ID: D95A2208-3031-44E8-862E-2877A042900D at 10.111.0.119
> >> CSeq: 1 INVITE
> >> From: "7005"<sip:7005 at 10.111.0.50:5060>;tag=12083790462495
> >> To: <sip:6007 at 10.111.0.20>;tag=0rxFXxkiza46soF7
> >> Contact: <sip:6007 at 10.111.0.144:5060>
> >> Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, REFER, NOTIFY, INFO,
> >> PRACK, UPDATE
> >> Supported: 100rel, replaces
> >> Content-Type: application/sdp
> >> Content-Length: 140
> >> Message body
> >> Session Description Protocol
> >> Session Description Protocol Version (v): 0
> >> Owner/Creator, Session Id (o): 6007 14194531 23224216 IN IP4
> >> 10.111.0.144
> >> Session Name (s): SIP CALL
> >> Connection Information (c): IN IP4 10.111.0.144
> >> Time Description, active time (t): 0 0
> >> Media Description, name and address (m): audio 10000 RTP/AVP 8
> >> Media Attribute (a): rtpmap:8 PCMA/8000
> >>
> >> No. Time Source Destination Protocol Info
> >> 10 3.751306000 10.111.0.20 10.111.0.50 SIP/SDP Status: 200 OK, with
> >> session
> >> description
> >> Session Initiation Protocol
> >> Status-Line: SIP/2.0 200 OK
> >> Message Header
> >> Via: SIP/2.0/UDP 10.111.0.50;branch=z9hG4bK2eff.75fbc652.0
> >> Via: SIP/2.0/UDP
> >> 10.111.0.119;rport=5060;branch=z9hG4bK0a6f0077000004b2452bb819000009f00000191e
> >>
> >> From: "7005"<sip:7005 at 10.111.0.50:5060>;tag=12083790462495
> >> To: <sip:6007 at 10.111.0.20>;tag=0rxFXxkiza46soF7
> >> Call-ID: D95A2208-3031-44E8-862E-2877A042900D at 10.111.0.119
> >> CSeq: 1 INVITE
> >> Contact: <sip:10.111.0.20:5060>
> >> Content-Type: application/sdp
> >> Content-Length: 140
> >> Message body
> >> Session Description Protocol
> >> Session Description Protocol Version (v): 0
> >> Owner/Creator, Session Id (o): 6007 14194531 23224216 IN IP4
> >> 10.111.0.144
> >> Session Name (s): SIP CALL
> >> Connection Information (c): IN IP4 10.111.0.144
> >> Time Description, active time (t): 0 0
> >> Media Description, name and address (m): audio 10000 RTP/AVP 8
> >> Media Attribute (a): rtpmap:8 pcma/8000
> >>
> >> No. Time Source Destination Protocol Info
> >> 11 3.751589000 10.111.0.50 10.111.0.119 SIP/SDP Status: 200 OK, with
> >> session description
> >> Session Initiation Protocol
> >> Status-Line: SIP/2.0 200 OK
> >> Message Header
> >> Via: SIP/2.0/UDP
> >> 10.111.0.119;rport=5060;branch=z9hG4bK0a6f0077000004b2452bb819000009f00000191e
> >>
> >> From: "7005"<sip:7005 at 10.111.0.50:5060>;tag=12083790462495
> >> To: <sip:6007 at 10.111.0.20>;tag=0rxFXxkiza46soF7
> >> Call-ID: D95A2208-3031-44E8-862E-2877A042900D at 10.111.0.119
> >> CSeq: 1 INVITE
> >> Contact: <sip:10.111.0.20:5060>
> >> Content-Type: application/sdp
> >> Content-Length: 140
> >> Message body
> >> Session Description Protocol
> >> Session Description Protocol Version (v): 0
> >> Owner/Creator, Session Id (o): 6007 14194531 23224216 IN IP4
> >> 10.111.0.144
> >> Session Name (s): SIP CALL
> >> Connection Information (c): IN IP4 10.111.0.144
> >> Time Description, active time (t): 0 0
> >> Media Description, name and address (m): audio 10000 RTP/AVP 8
> >> Media Attribute (a): rtpmap:8 pcma/8000
> >>
> >> No. Time Source Destination Protocol Info
> >> 12 3.756127000 10.111.0.119 10.111.0.50 SIP Request: ACK
> >> sip:10.111.0.20:5060
> >> Session Initiation Protocol
> >> Request-Line: ACK sip:10.111.0.20:5060 SIP/2.0
> >> Message Header
> >> Via: SIP/2.0/UDP
> >> 10.111.0.119;rport;branch=z9hG4bK0a6f0077000004b2452bb81d00000c5f00001922
> >> Content-Length: 0
> >> Call-ID: D95A2208-3031-44E8-862E-2877A042900D at 10.111.0.119
> >> CSeq: 1 ACK
> >> From: "7005"<sip:7005 at 10.111.0.50:5060>;tag=12083790462495
> >> Max-Forwards: 70
> >> To: <sip:6007 at 10.111.0.20>;tag=0rxFXxkiza46soF7
> >> User-Agent: SJphone/1.60.289a (SJ Labs)
> >>
> >> ________________________________
> >>
> >> _______________________________________________
> >> Serusers mailing list
> >> Serusers at lists.iptel.org
> >> http://lists.iptel.org/mailman/listinfo/serusers
> >>
> >>
> > _______________________________________________
> > Serusers mailing list
> > Serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> >
>
>
More information about the sr-users
mailing list