** NOTE: Submissions due on Mar 5, 2010 ***
** NOTE: Submissions due on Mar 5, 2010 ***
Dear Colleagues: IPTComm is one of the few conferences dedicated
solely to IP telecommunications. Please excuse the posting to
this list, but I believe that the conference will be of interest t
You are absolutely correct about RFC 3261.
In regard of RFC 2543 the situation is a bit more tricky, since it never
properly defines what matching To and From headers is supposed to mean. It
does talk about saving complete To and From headers in the dialog state as
local and remote addresses, and
At end...
Aaron Clauson wrote:
>> -Original Message-
>> From: Dale Worley [mailto:dwor...@avaya.com]
>> Sent: Monday, 22 February 2010 4:42 PM
>> On Thu, 2010-02-18 at 02:50 +, Aaron Clauson wrote:
>>
>> You should be able to do this in a standard way.
>>
>> First, let us assume that
> -Original Message-
> From: Dale Worley [mailto:dwor...@avaya.com]
> Sent: Monday, 22 February 2010 4:42 PM
> On Thu, 2010-02-18 at 02:50 +, Aaron Clauson wrote:
>
> You should be able to do this in a standard way.
>
> First, let us assume that an address of the client (which is acti
Offer:
- Session Description: media to flow from 192.168.2.103 from an X-Lite
softphone/CounterPath Eye Beam. Connection information included here as
part of session description
- Time Description: usual
- Media Description: Audio calls at port 34362 with two formats offered
0, 101. The only thing
The tag is used only by the UAs to indicate support for changed from/to
URIs, but for proxies which do not support changed from and To-URI this
new RFCs says there are no provisions and says as below
"This document makes no provision for proxies that are unable to
tolerate a change of URI, since
On Thu, 2010-02-18 at 02:50 +, Aaron Clauson wrote:
> I have a scenario where I want a SIP client to be able to generate multiple
> redirect responses. The redirect responses will be generated based on user
> actions and will have a variable delay between them.
>
> As far as I can see there is
Section 12.2.1.1 of 3261 talks about how the UAC constructs mid-dialog
requests and it concerns itself with how From and To *URI* and tags are
set. There's nothing in there suggesting that header parameters MUST or
even SHOULD be retained. The part about 2543 compatibility also does
not talk a
RFC 5658. Section 5.
On Mon, Feb 22, 2010 at 3:15 PM, SCG2 wrote:
> Hi,
>
>
>
> I am receiving a:
>
>
>
>
>
> SIP/2.0 200 OK
>
> From: ;tag=2A515F7C-E78
>
> To: ;tag=2852349aa700191083d2e580b676d2c3
>
> Via: SIP/2.0/UDP
> a...@b.c.e.f;branch=74120f13ef6c47555033517203dcd8ee.4;rport=5060;receive
>From RFC3261 page 29:
"The relative
order of header field rows with the same field name is important.
Multiple header field rows with the same field-name MAY be present in
a message if and only if the entire field-value for that header field
is defined as a comma-separated list (that
More info:
UAS is Fring wired into our own SIP server.
UAC happens to be a CISCO PSTN Gateway.
Fring is serving up multiple headers (on separate lines) in a 200 OK
response - which we don't see with Linksys, Polycom, XTen, etc.
So is there a rule for expressing this:
Record-Rout
Hi,
I am receiving a:
SIP/2.0 200 OK
From: ;tag=2A515F7C-E78
To: ;tag=2852349aa700191083d2e580b676d2c3
Via: SIP/2.0/UDP
a...@b.c.e.f;branch=74120f13ef6c47555033517203dcd8ee.4;rport=5060;received=a.b.
c.d
Via: SIP/2.0/UDP a...@b.c.e.f;branch=a3cfdc1207b90334f3dd00bc032115bf.2
Via:
12 matches
Mail list logo
