[prev in list] [next in list] [prev in thread] [next in thread]
List: sems
Subject: [Sems] Re: [Serdev] ser sems isdngw routing problems
From: jiri () iptel ! org (Jiri Kuthan)
Date: 2004-04-29 7:34:59
Message-ID: 6.0.3.0.0.20040429073314.037c1ec0 () localhost
[Download RAW message or body]
At 12:00 AM 4/29/2004, Ulrich Holeschak wrote:
>Hello,
>i have now captured the messages on the local interface (but without using
>loose_route()).
>
>The pcap file (readable with ethereal) could be found at
>http://www.holeschak.de/other/ser/sip_local.pcap
>
>I have added below the expanded 200 OK and the ACK message.
>
>As you could see, in the Message from the Messenger contains:
> Record-Route:
><sip:192.168.42.240;transport=tcp;r2=on;ftag=000049347922A395;lr=on>
> Record-Route: <sip:192.168.42.240;r2=on;ftag=000049347922A395;lr=on>
> Contact:
><sip:494755@router.local:14039;maddr=192.168.42.242;transport=tcp>
>
>And then in the ACK there could be found:
> Request-Line: ACK
>sip:494755@router.local:14039;maddr=192.168.42.242;transport=tcp SIP/2.0
> Route: <sip:192.168.42.240;r2=on;ftag=000049347922A395;lr=on>,
><sip:192.168.42.240;transport=tcp;r2=on;ftag=000049347922A395;lr=on>
>
>The ACK Packet should be finally routed to 192.168.42.242, but you can't
>find this Address in the Route.
>Is it really correct to use the route or is the route invalid? You could
>find 192.168.42.242 very often in the Packets, but not in the Route (E.g.
>maddr=192.168.42.242, Connection Address: 192.168.42.242 ...)
It is in contact. RFC2534-based strict routing uses Contacts for construction
of route set. I hope I explained all other information in my previous email.
>Perhaps this is a Microsoft specific handling that is a bit incompatible,
>but i think we should find a way to handle this ...
See my previous email, it states how to do it if there are volunteers wishing
to do so. (If maddr is put by obsoleted strict-routing implementations in
r-uri, replace hostname with value of maddr.)
-jiri
>Extracted Log:
>
>Frame 28 (791 bytes on wire, 791 bytes captured)
> Arrival Time: Apr 28, 2004 23:21:38.261983000
> Time delta from previous packet: 7.610787000 seconds
> Time since reference or first frame: 55.027532000 seconds
> Frame Number: 28
> Packet Length: 791 bytes
> Capture Length: 791 bytes
>Ethernet II, Src: 00:00:00:00:00:00, Dst: 00:00:00:00:00:00
> Destination: 00:00:00:00:00:00 (00:00:00_00:00:00)
> Source: 00:00:00:00:00:00 (00:00:00_00:00:00)
> Type: IP (0x0800)
>Internet Protocol, Src Addr: 192.168.42.240 (192.168.42.240), Dst Addr:
>192.168.42.240 (192.168.42.240)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)
> 0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
> .... ..0. = ECN-Capable Transport (ECT): 0
> .... ...0 = ECN-CE: 0
> Total Length: 777
> Identification: 0x4d7b (19835)
> Flags: 0x04
> 0... = Reserved bit: Not set
> .1.. = Don't fragment: Set
> ..0. = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: UDP (0x11)
> Header checksum: 0x1328 (correct)
> Source: 192.168.42.240 (192.168.42.240)
> Destination: 192.168.42.240 (192.168.42.240)
>User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
> Source port: 5060 (5060)
> Destination port: 5060 (5060)
> Length: 757
> Checksum: 0xb1ce (correct)
>Session Initiation Protocol
> Status-Line: SIP/2.0 200 OK
> Status-Code: 200
> Message Header
> Via: SIP/2.0/UDP 192.168.42.240;branch=z9hG4bK6d8.24345a57.0
> From: sip:6151494755@router.local;tag=000049347922A395
> SIP from address: sip:6151494755@router.local
> SIP tag: 000049347922A395
> To: sip:494755@router.local;tag=943ac04df08a49a1a99f048f4369f0f5
> SIP to address: sip:494755@router.local
> SIP tag: 943ac04df08a49a1a99f048f4369f0f5
> Call-ID: 0000493449E13A73@192.168.42.240
> CSeq: 11 INVITE
> Record-Route:
><sip:192.168.42.240;transport=tcp;r2=on;ftag=000049347922A395;lr=on>
> Record-Route: <sip:192.168.42.240;r2=on;ftag=000049347922A395;lr=on>
> Contact:
><sip:494755@router.local:14039;maddr=192.168.42.242;transport=tcp>
> User-Agent: RTC/1.2
> Content-Type: application/sdp
> Content-Length: 184
> Message body
> Session Description Protocol
> Session Description Protocol Version (v): 0
> Owner/Creator, Session Id (o): - 0 0 IN IP4 192.168.42.242
> Owner Username: -
> Session ID: 0
> Session Version: 0
> Owner Network Type: IN
> Owner Address Type: IP4
> Owner Address: 192.168.42.242
> Session Name (s): session
> Connection Information (c): IN IP4 192.168.42.242
> Connection Network Type: IN
> Connection Address Type: IP4
> Connection Address: 192.168.42.242
> Bandwidth Information (b): CT:1000
> Bandwidth Modifier: CT
> Bandwidth Value: 1000
> Time Description, active time (t): 0 0
> Session Start Time: 0
> Session Stop Time: 0
> Media Description, name and address (m): audio 31464 RTP/AVP 0 3
>8
> Media Type: audio
> Media Port: 31464
> Media Proto: RTP/AVP
> Media Format: 0
> Media Format: 3
> Media Format: 8
> Media Attribute (a): rtpmap:0 PCMU/8000
> Media Attribute Fieldname: rtpmap
> Media Attribute Value: 0 PCMU/8000
> Media Attribute (a): rtpmap:3 GSM/8000
> Media Attribute Fieldname: rtpmap
> Media Attribute Value: 3 GSM/8000
> Media Attribute (a): rtpmap:8 PCMA/8000
> Media Attribute Fieldname: rtpmap
> Media Attribute Value: 8 PCMA/8000
>
>Frame 29 (574 bytes on wire, 574 bytes captured)
> Arrival Time: Apr 28, 2004 23:21:38.279460000
> Time delta from previous packet: 0.017477000 seconds
> Time since reference or first frame: 55.045009000 seconds
> Frame Number: 29
> Packet Length: 574 bytes
> Capture Length: 574 bytes
>Ethernet II, Src: 00:00:00:00:00:00, Dst: 00:00:00:00:00:00
> Destination: 00:00:00:00:00:00 (00:00:00_00:00:00)
> Source: 00:00:00:00:00:00 (00:00:00_00:00:00)
> Type: IP (0x0800)
>Internet Protocol, Src Addr: 192.168.42.240 (192.168.42.240), Dst Addr:
>192.168.42.240 (192.168.42.240)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)
>
> 0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
> .... ..0. = ECN-Capable Transport (ECT): 0
> .... ...0 = ECN-CE: 0
> Total Length: 560
> Identification: 0x4d7c (19836)
> Flags: 0x04
> 0... = Reserved bit: Not set
> .1.. = Don't fragment: Set
> ..0. = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: UDP (0x11)
> Header checksum: 0x1400 (correct)
> Source: 192.168.42.240 (192.168.42.240)
> Destination: 192.168.42.240 (192.168.42.240)
>User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
> Source port: 5060 (5060)
> Destination port: 5060 (5060)
> Length: 540
> Checksum: 0x39ec (correct)
>Session Initiation Protocol
> Request-Line: ACK
>sip:494755@router.local:14039;maddr=192.168.42.242;transport=tcp SIP/2.0
> Method: ACK
> Message Header
> Via: SIP/2.0/UDP 192.168.42.240;branch=z9hG4bK6d8.24345a57.0
> From: sip:6151494755@router.local;tag=000049347922A395
> SIP from address: sip:6151494755@router.local
> SIP tag: 000049347922A395
> Call-ID: 0000493449E13A73@192.168.42.240
> To: sip:494755@router.local;tag=943ac04df08a49a1a99f048f4369f0f5
> SIP to address: sip:494755@router.local
> SIP tag: 943ac04df08a49a1a99f048f4369f0f5
> CSeq: 11 ACK
> Route: <sip:192.168.42.240;r2=on;ftag=000049347922A395;lr=on>,
><sip:192.168.42.240;transport=tcp;r2=on;ftag=000049347922A395;lr=on>
> User-Agent: Sip EXpress router(0.8.13-dev-28 (i386/linux))
> Content-Length: 0
>
>Thanks,
>
>Ulrich
>
>-----Urspr?ngliche Nachricht-----
>Von: "Klaus Darilion" <klaus.mailinglists@pernau.at>
>An: "Ulrich Holeschak" <UHoleschak@bihl-wiedemann.de>
>Cc: <serdev@iptel.org>; <sems@iptel.org>
>Gesendet: Mittwoch, 28. April 2004 15:39
>Betreff: [Sems] Re: [Serdev] ser sems isdngw routing problems
>
>
>> Have you tried to capture the ACK on the loopback device. How does it
>> look like?
>>
>> Ulrich Holeschak wrote:
>>
>> > Hello,
>> > i basically understand that it SHOULD be like that. But it seems that
>the
>> > routing information is invalid (or incorrect).
>> >
>> > At the moment i am using:
>> > ...
>> > if (loose_route()) {
>> > log("loose routing\n");
>> > # mark routing logic in request
>> > append_hf("P-hint: rr-enforced\r\n");
>> > route(1);
>> > break;
>> > };
>> > ...
>> >
>> > route[1]
>> > {
>> > # send it out now; use stateful forwarding as it works reliably
>> > # even for UDP2TCP
>> > if (!t_relay()) {
>> > sl_reply_error();
>> > };
>> > }
>> >
>> >
>> > So t_relay() IS called, after loose route. But the effect is, that the
>ACK
>> > is processed again by ser, and this time loose_route() is false. After
>this
>> > the normal processing with uri=myself and lookup() is called. The ACK
>is
>> > NEVER routed out of ser.
>> >
>> > Either the ACK should not be modified by loose_route() or the routing
>> > information is incorrect. (Or both)
>> >
>> > Ulrich
>> >
>> > -----Urspr?ngliche Nachricht-----
>> > Von: "Klaus Darilion" <klaus.mailinglists@pernau.at>
>> > An: "Ulrich Holeschak" <ulrich@holeschak.de>
>> > Cc: "Jiri Kuthan" <jiri@iptel.org>; <serdev@iptel.org>; <sems@iptel.org>
>> > Gesendet: Mittwoch, 28. April 2004 15:13
>> > Betreff: Re: [Serdev] ser sems isdngw routing problems
>> >
>> >
>> >
>> >>
>> >>Ulrich Holeschak wrote:
>> >>
>> >>>Hello,
>> >>>now i have commented out loose_route() in the routing script and things
>> >
>> > are
>> >
>> >>>running well!
>> >>>
>> >>>The problem is, that loose_route() replaces the uri
>> >>>sip:494755@router.local:15903;maddr=192.168.42.242;transport=tcp
>> >>>with:
>> >>>sip:192.168.42.240;transport=tcp;r2=on;ftag=000031287421C96D;lr=on
>> >>>(192.168.42.240 is identical with router.local)
>> >>>But this could not be processed by lookup("location") any more, because
>> >
>> > the
>> >
>> >>>router and gateway name is lost ...
>> >>
>> >>If a request is handled by the loose_route blcok, you should not do a
>> >>lookup. The lookup is not necessary, as all the routing information is
>> >>already in the message (in the request URI and in the Route: headers)
>> >>and it can be forwarded with t_relay().
>> >>
>> >>klaus
>> >>
>> >>
>> >>>Without calling loose_route() lookup("location") replaces the uri with:
>> >>>sip:192.168.42.242:15472;transport=tcp
>> >>>what is the correct destination.
>> >>>
>> >>>As i can see it by now, the ACK is NOT generated by sems, but by ser
>> >>>locally.
>> >>>
>> >>>So now there is the question, what is the correct solution for the
>> >
>> > problem?
>> >
>> >>>Is the ACK generated badly, so that loose_route() processes it?
>> >>>Or should i only call loose_route() for telegrams with not
>(uri==myself)
>> >
>> > or
>> >
>> >>>not for acks?
>> >>>
>> >>>You told me before some time, that t_newtran() should process the ack.
>I
>> >>>tried it, but it fails. How should t_newtran() know that the ACK should
>> >
>> > be
>> >
>> >>>send to
>> >>>192.168.42.242? I thinky only lookup() knows this ...
>> >>>
>> >>>Ulrich
>> >>>
>> >>>
>> >>>----- Original Message -----
>> >>>From: "Jiri Kuthan" <jiri@iptel.org>
>> >>>To: <ulrich@holeschak.de>
>> >>>Cc: <serdev@iptel.org>; <sems@iptel.org>
>> >>>Sent: Monday, April 26, 2004 9:20 PM
>> >>>Subject: Re: [Serdev] ser sems isdngw routing problems
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>qAt 01:19 PM 4/26/2004, ulrich@holeschak.de wrote:
>> >>>>
>> >>>>
>> >>>>>Hello, thanks for the answer.
>> >>>>>
>> >>>>>Have you already seen the etherreal log file at:
>> >>>>>http://www.holeschak.de/other/ser/sip_fail.eth?
>> >>>>
>> >>>>I looked at it (sip_scenario-ized at
>> >>>
>> >>>http://www.iptel.org/~jiri/etc/hol/sip_fail_index.html)
>> >>>
>> >>>
>> >>>>and it seems to me that you lost an ACK somewhere. A 200 must be
>> >
>> > followed
>> >
>> >>>by
>> >>>
>> >>>
>> >>>>ACK.
>> >>>>
>> >>>>Supposingly, that's related to the problem I described to you
>> >>>>in my previous problem. Messenger generated an maddr contact uri
>> >>>>(F4: Contact:
>> >>>
>> >>><sip:494755@router.local:15903;maddr=192.168.42.242;transport=tcp> )
>> >>>
>> >>>
>> >>>>in which maddr will be ignored. Consequently, the ACK begins to loop,
>> >>>>I guess, and the call nevers gets set up.
>> >>>>
>> >>>>-jiri
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>>It's only a part of the communication (begins with call from PSTN
>phone
>> >>>>>until connection breaks).
>> >>>>>
>> >>>>>What i don't understand at the moment is how and were is the ack
>> >>>
>> >>>generated?
>> >>>
>> >>>
>> >>>>>Is this automatically done by ser or is it created by sems? In the
>> >
>> > syslog
>> >
>> >>>i
>> >>>
>> >>>
>> >>>>>can see no sems entry regarding this ack. (or is this not logged?)
>> >>>>>
>> >>>>>If the ack comes from sems, why and where is it modified in ser (with
>> >
>> > the
>> >
>> >>>>>maddr part)?
>> >>>>>If it's right what you say, that the ack sould be consumed by
>> >>>
>> >>>t_newtran(),
>> >>>
>> >>>
>> >>>>>why is this not done?
>> >>>>>But also in the working release version of ser the ACK is processed
>by
>> >>>>>lookup("location"). The importent thing is that lookup() rewrites the
>> >>>
>> >>>header
>> >>>
>> >>>
>> >>>>>with 'sip:192.168.42.242:7723;transport=tcp' otherwhise the ACK would
>> >>>
>> >>>never
>> >>>
>> >>>
>> >>>>>reach the target ...
>> >>>>>
>> >>>>>Apr 24 23:40:37 router ser[25621]: SIP Request:
>> >>>>>Apr 24 23:40:37 router ser[25621]: method: <ACK>
>> >>>>>Apr 24 23:40:37 router ser[25621]: uri:
><sip:494755@router.local>
>> >>>>>Apr 24 23:40:37 router ser[25621]: version: <SIP/2.0>
>> >>>>>...
>> >>>>>Apr 24 23:40:37 router ser[25621]: check_self - checking if host==us:
>> >>>
>> >>>12==12
>> >>>
>> >>>
>> >>>>>&& [router.local] == [router.local]
>> >>>>>Apr 24 23:40:37 router ser[25621]: check_self - checking if port 5060
>> >>>>>matches port 5060
>> >>>>>Apr 24 23:40:37 router ser[25621]: rwrite(): Rewriting Request-URI
>with
>> >>>>>'sip:192.168.42.242:7723;transport=tcp'
>> >>>>>Apr 24 23:40:37 router ser[25621]: DEBUG: t_addifnew: msg id=1 ,
>global
>> >>>
>> >>>msg
>> >>>
>> >>>
>> >>>>>id=0 , T on entrance=0xffffffff
>> >>>>>Apr 24 23:40:37 router ser[25621]: parse_headers: flags=-1
>> >>>>>Apr 24 23:40:37 router ser[25621]: parse_headers: flags=60
>> >>>>>Apr 24 23:40:37 router ser[25621]: t_lookup_request: start searching:
>> >>>>>hash=7092, isACK=1
>> >>>>>Apr 24 23:40:37 router ser[25621]: parse_headers: flags=28
>> >>>>>Apr 24 23:40:37 router ser[25621]: DEBUG: t_lookup_request: e2e proxy
>> >
>> > ACK
>> >
>> >>>>>found
>> >>>>>Apr 24 23:40:37 router ser[25621]: SER: forwarding ACK statelessly
>> >>>>>
>> >>>>>Thanks,
>> >>>>>
>> >>>>>Ulrich
>> >>>
>> >>>
>> >>>_______________________________________________
>> >>>Serdev mailing list
>> >>>Serdev@iptel.org
>> >>>http://mail.iptel.org/mailman/listinfo/serdev
>> >>>
>> >>>
>> >
>> >
>> >
>>
>> _______________________________________________
>> Sems mailing list
>> Sems@iptel.org
>> http://mail.iptel.org/cgi-bin/mailman/listinfo/sems
>
>_______________________________________________
>Serdev mailing list
>Serdev@iptel.org
>http://mail.iptel.org/mailman/listinfo/serdev
--
Jiri Kuthan http://iptel.org/~jiri/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic