[Serusers] PRACK on forked response

[Stephen Paterson]

Hi Michal,
Thanks for the reply and sorry for the delay. Had me a nice relaxing long weekend in the country!
Anyhow, I've not set up anything special in the config file. I just installed SER and ran it straight out of the box as it were. It worked fine for my purposes so I felt no need to tinker with the config. 
There is no mention of forking or lookup_contacts in the config. Diff shows the only difference between my config file and the simple example one that comes with the distribution is at the top in the global configuration parameters section where I set a listen address. All the routing logic is identical.
Cheers
Steve

-----Original Message-----
From: Michal Matyska [mailto:michal.matyska at iptel.org] 
Sent: 09 July 2008 15:11
To: Stephen Paterson
Cc: serusers at iptel.org
Subject: Re: [Serusers] PRACK on forked response

Hi,

SER does not care about PRACK... it is just another within-dialog request type, like BYE and many others.

I think you have incorrect routing script logic, where you fork even the within dialog requests (using lookup_contacts) instead of just following the record route set.

Michal


Stephen Paterson píše v St 09. 07. 2008 v 14:01 +0100:
> Hi all,
> 
> I'm using SER purely for testing purposes just now. Currently testing 
> our handling of forked responses and hit upon the following situation:
> 
> My outgoing INVITE is forked to two UASs (also our own SIP endpoint), 
> one of which sends a reliable 180 and the other an unreliable 180. The 
> UAC sends a PRACK on the dialog ID of the reliable response but SER 
> forwards this response on to both UASs the result being the UAS that 
> sent the unreliable 180 responds to the PRACK with a 481 (the PRACK 
> contains a To-tag that part defines a dialog unknown to that UAS). I 
> confess I can't find anything describing this scenario in any RFC but 
> it strikes me as incorrect behaviour on SERs part.
> 
> Does SER support PRACK? If not then no matter, I can live with it - it 
> doesn't affect the outcome of any call. If it does, does anyone have 
> any thoughts on this?
> 
> Cheers
> 
> Steve
> 
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
> MK1 1PT, UK
> Registration No: 1397386 (Wales)
>  
>  P Please consider the environment and don't print this e-mail unless
>                           you really need to
> 
> 
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers

Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)  
P Please consider the environment and don't print this e-mail unless you really need to