15 Mar
2005
15 Mar
'05
4:10 p.m.
Hi all!
Now I'm also confused. As you see from the following CVS commit,
loose_route should always return 1, whenever record-routing is used. I
would imply that now every in-dialog request should cause loose_route to
return 1. But obviously this is not the case because then we wouldn't
have to discuss here.
regards,
klaus
janakj 2004/11/11 15:45:47 CET
SER CVS Repository
Modified files: (Branch: rel_0_8_14)
modules/rr loose.c
Log:
- loose_route now returns 1 whenever record-routing is used to route the
message (backported from HEAD)
Revision Changes Path
1.26.4.1.2.1 +4 -8 sip_router/modules/rr/loose.c
Cesc Santasusana wrote:
Hi,
In a different scenario from yours, i encountered the same problem of
loose_route() unexpectedly returning false.
In my case, it was when i was running a softphone on the same computer
as the ser proxy. If someone would send
a routed message to the phone, for example a BYE, or a re-INVITE, SER
would return false at the loose_route() function. This means that ser
identifies the previous hop as doing strict routing.
I was able to solve this by removing the ser-proxy IP address from the
alias="...." list in ser.cfg, and then using the domain module to gain
back the same functionality (or close) when doing the uri==myself.
Don't know how your ser.cfg looks like, but just thought that maybe
this might be useful.
Regards,
Cesc
>>Klaus Darilion
<klaus.mailinglists(a)pernau.at> 03/15/05 11:04AM >>>
Hi Paul!
That something I also asked several times and no answer yet. In my
experience, loose_route() is true if the request URI contains the "lr"
paramter (message comes from a strict router). Nevertheless, the
loose_route function will remove its own Route: header.
I solve the troubles by allowing t_relay for all messages with to-tag
(in-dialog).
regards,
klaus
Java Rockx wrote:
Unclassified
Hi All.
I just don't see why loose_route() returned FALSE for this INVITE
message. Can anyone help?
This INVITE was sent from my SIP phone to my SER-0.9 proxy. The IPs
look funny because our SER proxy sits behind a Cisco 3600 and the
ALG
stuff has rewritten the IPs (ie, the 10.3.0.221
address).
Regards,
Paul
U 2005/03/14 16:01:19.932196 69.200.205.122:5060 -> 10.3.0.221:5060
INVITE sip:9195531888@66.243.109.99:5060;user=phone SIP/2.0.
Via: SIP/2.0/UDP 69.200.205.122:5060;branch=z9hG4bK2434592534.
Route: <sip:10.3.0.221;ftag=10000000-0-1811969809;lr>.
Route: <sip:216.229.127.60:5060;lr>.
From: 3475626630
<sip:3475626630@66.243.109.99:5060;user=phone>;tag=550070175.
To:
<sip:9195531888@64.152.60.6;user=phone>;tag=10000000-0-1811969809.
Call-ID: 348926-3319820023-453493(a)66.243.109.99.
CSeq: 1 INVITE.
Contact: <sip:3475626630@69.200.205.122:5060>.
max-forwards: 70.
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE.
Content-Type: application/sdp.
Content-Length: 171.
.
v=0.
o=- 9528 3044 IN IP4 0.0.0.0.
s=-.
c=IN IP4 0.0.0.0.
t=0 0.
m=audio 13456 RTP/AVP 18 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendonly.
a=ptime:20.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers