HI Bogdan,
thanks. Thats what did it. Turns out it was a sipp config problem after all. Incidentally the UA's that worked for me was a sipura and x-lite.
Thanks, Andy
On 2/25/07, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Andy,
yes, you are correct - the package 7 (the 200 OK) must mirror the Record-Route set from the request. For this you need to enable the rrs param :
<recv request="INVITE" crlf="true" rrs="true"> </recv>
regards, bogdan
Andy Pyles wrote:
Hi Bogdan,
ok let me go back to my example:
Here's more detail: 192.168.0.101 = Caller (sipp uas) 1.2.3.4 = openser 4.3.2.1 = callee ( sipp uac)
1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE sip:service@1.2.3.4:5060, with session description 2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try 3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE sip:service@4.3.2.1:5060, with session description 4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing 5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session description 6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing 7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, with session description 8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK sip:service@1.2.3.4:5060 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK sip:service@4.3.2.1:5060 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE sip:service@1.2.3.4:5060 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE sip:service@4.3.2.1:5060 12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK 13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK
So, you are saying for Packets 8, 10 I should add the '[routes]' logic to sipp. How this works is: from the sipp documentation: "rrs: Record Route Set. if this attribute is set to "true", then the "Record-Route:" header of the message received is stored and can be recalled using the [routes] keyword.".
This I completey agree with. sipp Must be sending the Route: header in Packets 8 and 10. However, packet 7 MUST have the Record-route header, otherwise, How can sipp can put the correct value into the Route: header. See my point?
Reference: rfc 3665 ( secion 3.2 Packet f11, f14)
regards, Andy
On 2/23/07, Andy Pyles andy.pyles@gmail.com wrote:
Hi Bogdan,
correct. but on client config "[routes]" ( for sipp) will only work IF the client receives a Record-route. Since I'm not, it doesn't help me. Am I missing something?
Andy
On 2/23/07, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Andy,
in client config, you need to add "[routes]" for ACK and BYE messages (take a look at the cfg I sent you)
regards, bogdan
Andy Pyles wrote:
I Just re-read the docs on loose_route(). So please disregard this question. ( only processed if Route: header is present. Which isn't present because Record-route: header isn't being sent to caller )
So, I'm still trying to figure out why record-route: header is not being sent to caller.
On 2/22/07, Andy Pyles andy.pyles@gmail.com wrote:
Hi Bogdan,
After running additional debugs, for some reason the call to loose_route() is failing.
if (loose_route()) { # mark routing logic in request xlog("L_INFO", "loose_route() succeeded\n "); route(1); } else{ xlog("L_INFO", "loose_route()failed - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); };
Any ideas why this could be occuring?
On 2/22/07, Andy Pyles andy.pyles@gmail.com wrote: > HI Bogdan, > > I'm already using an almsot identical version of uas.xml and
uac.xml (
> yes rrs=true) is being used. However in your version the uas.xml > doesn't have rrs="true" after initial invite which I think is
needed.
> See as you can see below, setting rrs="true" for uac will only
work if
> it receives a Record-Route header in the 200OK which it's not. > > In this case, ALL messages from openser to sipp uac do not
contain the
> Record-route header. So I don't think it's a sipp problem, but an > openser configuration problem. I've tried using other devices
for a
> uac, such as x-lite but the same problem. > > Andy > > On 2/22/07, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote: > > Hi Andy, > > > > so it's about sipp :D - I remember I had some hard times to
make
it work > > with record Route. > > > > take a look at the attached files, they might help you. > > > > regards, > > bogdan > > > > Andy Pyles wrote: > > > HI Bogdan, > > > > > > thanks for your reply. > > > yes you are correct. The Bye doesn't have the Route header. > > > It appears the the 200 OK sent to the caller doesn't
contain a
> > > Record-route header. > > > Messages between openser and callee contain record-route information, > > > but messages between caller and openser do not. > > > Is there a way to enable that? > > > > > > Here's more detail: > > > 192.168.0.101 = Caller (sipp) > > > 1.2.3.4 = openser > > > 4.3.2.1 = callee ( sipp) > > > > > > > > > 1.) 192.168.0.101 -> 1.2.3.4 SIP/SDP Request: INVITE > > > sip:service@1.2.3.4:5060, with session description > > > 2.) 1.2.3.4 -> 192.168.0.101 SIP Status: 100 Giving a try > > > 3.) 1.2.3.4 -> 4.3.2.1 SIP/SDP Request: INVITE > > > sip:service@4.3.2.1:5060, with session description > > > 4.) 4.3.2.1 -> 1.2.3.4 SIP Status: 180 Ringing > > > 5.) 4.3.2.1 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session > > > description > > > 6.) 1.2.3.4 -> 192.168.0.101 SIP Status: 180 Ringing > > > 7.) 1.2.3.4 -> 192.168.0.101 SIP/SDP Status: 200 OK, with session > > > description > > > 8.) 192.168.0.101 -> 1.2.3.4 SIP Request: ACK > > > sip:service@1.2.3.4:5060 > > > 9.) 1.2.3.4 -> 4.3.2.1 SIP Request: ACK sip:service@4.3.2.1:5060 > > > 10.) 192.168.0.101 -> 1.2.3.4 SIP Request: BYE > > > sip:service@1.2.3.4:5060 > > > 11.) 1.2.3.4 -> 4.3.2.1 SIP Request: BYE sip:service@4.3.2.1:5060 > > > 12.) 4.3.2.1 -> 1.2.3.4 SIP Status: 200 OK > > > 13.) 1.2.3.4 -> 192.168.0.101 SIP Status: 200 OK > > > > > > --- > > > Packets 6,7 and following contain no Record-route
information.
> > > The other weird thing is that openser is passing on the
Route:
header > > > it recevied from callee to the caller. > > > > > > > > > Please see attached for complete ngrep output. > > > > > > > > > On 2/21/07, Bogdan-Andrei Iancu bogdan@voice-system.ro
wrote:
> > >> Hi Andy, > > >> > > >> could you check on the net if the BYE contain the Route hdr added to > > >> INVITE as Record-Route? I have some doubts on this as I see: > > >> 0(966) find_first_route: No Route headers found > > >> 0(966) loose_route: There is no Route HF > > >> > > >> and if the BYE is not identified, the dialog is not closed. > > >> > > >> regards, > > >> bogdan > > >> > > >> Andy Pyles wrote: > > >> > Hello, > > >> > > > >> > I have a question on how to configure the dialog module ( 1.2.x from > > >> > cvs yesterday ). > > >> > > > >> > With my config, ( attached) I can make calls and have verified that > > >> > the acc module is working correctly. > > >> > > > >> > My question is, when I enable the dialog module, I can see that it is > > >> > incrementing call count correctly, but when a bye is received, the > > >> > dialog:active_dialogs statistic is never decremented. > > >> > > > >> > In the debug level 9 logs, ( also attached) I see this
error
after the > > >> > 200OK is sent to the bye: > > >> > > > >> > 1(969) DBUG:dialog:unref_dlg: unref dlg 0xa7ce5a98 with 1 > > >> (delete=0)-> 1 > > >> > > > >> > Is this a case of one of the timers being set too
short? by
the way > > >> > using a variable call length from well under a second ( using sipp ) > > >> > to 20 second call doesnt' seem to make a difference . > > >> > > > >> > > > >> > Thanks, > > >> > Andy > > >> >