[Sems] Re: [Serdev] ser sems isdngw routing problems
Ulrich Holeschak
ulrich at holeschak.de
Sun May 2 00:10:19 UTC 2004
Hello,
now i found time to test your hint to replace hostname with maddr. It works
fine. If somebody ist interested in the part of the script it follows here.
Perhaps it would be good to add it somewere to an example (if it is correct
and usefull), because i think i am not the only one who has problems with
windows messenger ...
route{
...
# for Windows Messenger: route ACK's to maddr destination
if (method=="ACK") {
if(uri=~"sip:.*@.*:[0-9]*;maddr=.*;.*"){
log("replace destination with maddr in ACK\n");
exec_dset("
NEW_URI=`echo $SIP_RURI | sed -e
's/\(sip:\)\(.*@.*\)\(:[0-9]*;\)\(maddr=\)\(.*\)\;/\1\5\3/'`
echo $NEW_URI
echo > /dev/null
");
route(1);
break;
}
}
# By default we record route everything except REGISTERs
if (!(method=="REGISTER")) record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
break;
};
if (uri==myself) {
....
route[1]
{
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
}
Ulrich
----- Original Message -----
From: "Jiri Kuthan" <jiri at iptel.org>
To: "Ulrich Holeschak" <Ulrich at Holeschak.de>; "Klaus Darilion"
<klaus.mailinglists at pernau.at>
Cc: <serdev at lists.iptel.org>; <sems at lists.iptel.org>
Sent: Thursday, April 29, 2004 7:36 AM
Subject: Re: [Sems] Re: [Serdev] ser sems isdngw routing problems
> 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 at router.local:14039;maddr=192.168.42.242;transport=tcp>
> >
> >And then in the ACK there could be found:
> > Request-Line: ACK
> >sip:494755 at 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 at router.local;tag=000049347922A395
> > SIP from address: sip:6151494755 at router.local
> > SIP tag: 000049347922A395
> > To: sip:494755 at router.local;tag=943ac04df08a49a1a99f048f4369f0f5
> > SIP to address: sip:494755 at router.local
> > SIP tag: 943ac04df08a49a1a99f048f4369f0f5
> > Call-ID: 0000493449E13A73 at 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 at 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 at 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 at router.local;tag=000049347922A395
> > SIP from address: sip:6151494755 at router.local
> > SIP tag: 000049347922A395
> > Call-ID: 0000493449E13A73 at 192.168.42.240
> > To: sip:494755 at router.local;tag=943ac04df08a49a1a99f048f4369f0f5
> > SIP to address: sip:494755 at 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 at pernau.at>
> >An: "Ulrich Holeschak" <UHoleschak at bihl-wiedemann.de>
> >Cc: <serdev at lists.iptel.org>; <sems at lists.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 at pernau.at>
> >> > An: "Ulrich Holeschak" <ulrich at holeschak.de>
> >> > Cc: "Jiri Kuthan" <jiri at iptel.org>; <serdev at lists.iptel.org>;
<sems at lists.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 at 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 at iptel.org>
> >> >>>To: <ulrich at holeschak.de>
> >> >>>Cc: <serdev at lists.iptel.org>; <sems at lists.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 at 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 at 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 at 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 at lists.iptel.org
> >> >>>http://lists.iptel.org/mailman/listinfo/serdev
> >> >>>
> >> >>>
> >> >
> >> >
> >> >
> >>
> >> _______________________________________________
> >> Sems mailing list
> >> sems at lists.iptel.org
> >> http://lists.iptel.org/cgi-bin/mailman/listinfo/sems
> >
> >_______________________________________________
> >Serdev mailing list
> >serdev at lists.iptel.org
> >http://lists.iptel.org/mailman/listinfo/serdev
>
> --
> Jiri Kuthan http://iptel.org/~jiri/
>
More information about the Serdev
mailing list