From: Ivar Lumi <[EMAIL PROTECTED]>
/*
If the domain of the Request-URI indicates a domain this element is
not responsible for,
the Request-URI MUST be placed into the target set as the only
target, and the
element MUST proceed to the task of Request Forwardi
Harsha. R wrote:
> Hi,
> Consider the following scenario with regard to session-refresh
>
> INVITE[Min SE:900, (SE:900,refresher=uas),k:timer]
> UAC->UAS
>
> 183 SP,PRACK(183),200OK PRACK,180 Ringing, PRA
Hi,
/*
If the domain of the Request-URI indicates a domain this element is
not responsible for,
the Request-URI MUST be placed into the target set as the only
target, and the
element MUST proceed to the task of Request Forwarding (Section 16.6).
*/
Whats meant under domain ?
Lik
Thanks Brett, that's just what I need.
Shame it means we're in the wrong but I prefer to be clear and wrong
rather than have no idea.
Thanks for the other replies. I have what I need now.
Cheers
Steve
-Original Message-
From: Brett Tate [mailto:[EMAIL PROTECTED]
Sent: 16 January 2008 16:
There is no real meaning to transport parameter in From or To header. So
UAS should just ignore it. Rejecting request based on it, does not seem
correct.
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On
>Behalf Of Stephen Paterson
>Sent: Wednesday, January 16,
On Wed, 2008-01-16 at 16:11 +, Stephen Paterson wrote:
> Hi Srini,
>
> It is also present in the Contact, Via and Request-Line and as I
> understand it, these are necessary requirements (well, if future
> communication is to be over TCP) but that's not the question.
>
> The question is, is i
Stephen,
RFC 3263 Section 4.1 may answer your question. I quote
" If the URI specifies a transport protocol in the transport parameter,
that transport protocol SHOULD be used."
Regards
Harsha
On 16/01/2008, Stephen Paterson <[EMAIL PROTECTED]> wrote:
> Hi Srini,
>
> It is also present in
The table within rfc3261 section 19.1.2 reflects the sip-uri parameters
allowed when used within To and From. Note that transport has
explicitly been made not optional. If I recall correctly, transport and
other routing related parameters were excluded because the working group
did not want them
Hi Srini,
It is also present in the Contact, Via and Request-Line and as I
understand it, these are necessary requirements (well, if future
communication is to be over TCP) but that's not the question.
The question is, is it valid to have transport=tcp as a URI parameter in
the To and From header
Isn't the "Contact" header more appropriate for Uas to indicate
the transport preference? Contact headers turn into request-URIs on the
way back and the proxies and UAs route on request-URIs/Route headers,
right?. We would obviously use the Via headers to indicate TCP properly
(SIP/2.0/TC
Hi all,
When using TCP, we place 'transport=tcp' in both the To and From headers
and it is claimed that the presence of this in the From header is
invalid (interestingly the To header is not causing any grief). It seems
to me that the From and To headers contain URIs and transport=tcp is a
valid U
Hi all,
Consider the following scenarios.
1.
C->S: INVITE (for speechrecog)
S->C: 200 OK
C->S: ACK
Now the SIP session is established b/w UAC and UAS. speechrecog resource is
active on the established sip session
C->S: INVITE (re-INVITE for adding speechsynth resource)
S->C: 200
I think you have answered your own question very well
with excellent references (it nicely saves everyone else's time!).
:-)
(UAS is not allowed to increase the SE)
Regards,
Attila
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Harsha. R
Sent: 16 J
> Now my question is, since UAC has clearly set the
> MinSE(900) andSE(900) values in the Session-Refresh
> request and chosen UAS as the refresher in the process,
> is UAS allowed the latitude to INCREASE the value of
> Session Expires header to 1800 in the response
> to Session-Refresh reque
Hi,
Consider the following scenario with regard to session-refresh
INVITE[Min SE:900, (SE:900,refresher=uas),k:timer]
UAC->UAS
183 SP,PRACK(183),200OK PRACK,180 Ringing, PRACK(180),200 OK PRACK follow
Your scenarios below are confusing and incomplete. Its hard to
understand the point you are trying to make. More inline...
Srinivas wrote:
> Hi all,
> Consider the following scenarios.
>
> 1.
> C->S: INVITE (for speechrecog)
> S->C: 200 OK
> C->S: ACK
>
>
On Wed, 2008-01-16 at 09:45 +0100, Iñaki Baz Castillo wrote:
> On Tuesday 15 January 2008 19:11:21 Scott Lawrence wrote:
> > Why both instead of just using one or the other?
> >
> > While it's possible that this is technically legal, it certainly is not
> > the way most implementations do it (the
Hi all,
Consider the following scenarios.
1.
C->S: INVITE (for speechrecog)
S->C: 200 OK
C->S: ACK
Now the SIP session is established b/w UAC and UAS. speechrecog
resource is active on the established sip session
C->S: INVITE (re
Thanks a lot Castillo
-
Mahesh
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
On Monday 14 January 2008 10:16:00 Mahesh_Pidshetty wrote:
> Hi all,
>
> I am bit bemused with the parameter maddr.
>
> I would be glad if someone delineate the exact meaning and usage of maddr
> parameter.
>
> The remaining test cases are pending for our company product because of
> not getting c
On Tuesday 15 January 2008 20:58:14 Christian Stredicke wrote:
> 1. Take a look at the Reason header. This way, the phone can determine why
> the CANCEL request was sent and make a decision if that was a missed call
> or not.
Depending on the context this Reason header could not be enough.
Imagine
On Tuesday 15 January 2008 19:11:21 Scott Lawrence wrote:
> Why both instead of just using one or the other?
>
> While it's possible that this is technically legal, it certainly is not
> the way most implementations do it (the first I've heard of it,
> actually) and it may confuse some UAs.
I use
22 matches
Mail list logo
