9 Jul
2008
9 Jul
'08
4:01 p.m.
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
9 Jul
9 Jul
5:11 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
15 Jul
15 Jul
12:20 p.m.
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@iptel.org]
Sent: 09 July 2008 15:11
To: Stephen Paterson
Cc: serusers(a)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(a)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
5980
days inactive
5986
days old
2 comments
2 participants
participants (2)
-
Michal Matyska -
Stephen Paterson