Hi,
If normal Re-invite or UPDATE are processed after session timer is
negotiated in call, will it extend the session interval for refresh.
For example, A and B negotiates 3600 seconds for session refresh and A is
the refresher.
Suppose A holds after 500 seconds,i.e A send Re-invite to B, will
Any re-INVITE or UPDATE (provided it contains the correct Session Timer
headers) will refresh the session.
offer-answer exchange is not relevant with respect to refreshing
the session. In other words, SDP content has no effect on the session
refresh timers.
Regards,
Attila
-Original
You can use the SDP parameter a = 'sendonly' or a = 'recvonly'
- Original Message
From: Darshan Bildikar [EMAIL PROTECTED]
To: sip-implementors@cs.columbia.edu
Cc: Padma Priya R [EMAIL PROTECTED]
Sent: Tuesday, 12 December, 2006 6:04:38 PM
Subject: [Sip-implementors] About hold criteria
Hi,
Can we change the From/To header value (caller id part and not from tag)
after dialog is established.
My understanding is except tag anything can be changed in From header.
We have requirement to show different caller id in case of transfers where
A is first connected to B so A will have
INVITE retries during call setup is an interesting choice
for keeping
the pinhole open. It sounds like everyone will continue to be
creative until the outbound draft is finalized and implemented.
Is this really so odd? RFC 3581 (which is standards track) says:
To keep the
I am out of the office traveling in Asia on business from Monday 12/11 through
Monday 12/18. If this is an urgent issue, please contact Tricia Streilein at
(781) 771-8321 or by email at [EMAIL PROTECTED]
___
Sip-implementors mailing list
Hi Brett,
Yep, I think you're right.
I'm really not sure if I'm correct. :)
Cheers,
Attila
PS But I really wish the UAC would cease retransmitting its INVITEs.
I'm sure there's a rule about that somewhere ;-)
Unfortunately, Gary it correct about rfc3581 recommending resending the
RFC 3261 mentions that From/To headers, without the tag, can be changed
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006 8:57 AM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors]
Attila Sipos wrote:
Any re-INVITE or UPDATE (provided it contains the correct Session Timer
headers) will refresh the session.
I'd clarify that:
Any successful re-INVITE or UPDATE will redetermine whether a session
timer is in effect and if so establish a new value for the timer.
So if the
RFC 3261 mentions that From/To headers, without the tag, can
be changed
The rfc3261 indicates To/From uri's currently cannot change because of
backward compatibility with rfc2543. However it does indicate that this
backward compatibility requirement might be deprecated by a subsequent
RFC.
Short version: does the address field in the origin line have any
particular significance
in SIP? I'm thinking no, but would appreciate a second opinion.
Long version:
Here's an snippet from a 183 response with SDP answer that I captured:
Contact: sip:[EMAIL PROTECTED]:1
o=Sonus_UAC 7952
Greetings,
RFC3261 section 17.2.3 indicates that the Via sent-by is used as part of
the transaction matching when the magic cookie is present. The Via
sent-by usually reflects the meaning presented within Via's bnf. Does
the sent-by portion of the matching rules really just include Via's
Q1. say you send an INVITE and you get a 302 response with
Contact: sip:[EMAIL PROTECTED];sdfs=sd;msdf=21342;shabba=dabba
When you send the redirected INVITE (the INVITE triggered by
the 302), what SIP URI request line should you have?
I think it should be:
INVITE
Brett,
The standard does not foresee including 'received' in the comparison. I
guess it could help in case one is concerned about bogus sent-by values (ie
host names / IP addresses), but adding special processing for clients that
are not following the rules is IMHO a bad idea. Better to treat
Thanks Brett, Gary and Attila for sharing your views.
If the reliability is the only objective for
retranmission, then in my scenario UAC should not
retransmit INVITE as it has received 180 and more so
it has experienced PRACK-200 successfully.
Thanks again to Gary for pointing out RFC 3581. I was
I am out of the office traveling in Asia on business from Monday 12/11 through
Monday 12/18. If this is an urgent issue, please contact Tricia Streilein at
(781) 771-8321 or by email at [EMAIL PROTECTED]
___
Sip-implementors mailing list
Inline
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Attila Sipos
Sent: Wednesday, December 13, 2006 3:56 PM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] 2 questions on 3xx response
Q1. say you send an INVITE and you get a
Attila,
Q1. say you send an INVITE and you get a 302 response with
I think it should be:
INVITE sip:[EMAIL PROTECTED];sdfs=sd;msdf=21342;shabba=dabba SIP/2.0
I concur, based on rfc3261, section 8.1.3.4.
Q2. you have an a UA and it has an outbound proxy configured.
when you
Q1. I think, it's not right.
If Contact in 302 is
sip:[EMAIL PROTECTED];sdfs=sd;msdf=21342;shabba=dabba
then Request URI of redirected INVITE would be
INVITE sip:[EMAIL PROTECTED] SIP/2.0
Rather if Contact in 302 is
sip:[EMAIL PROTECTED];sdfs=sd;msdf=21342;shabba=dabba
then Request URI of
Hello, Attila
On 13.12.2006, 23:55, Attila Sipos [EMAIL PROTECTED] wrote to
sip-implementors@cs.columbia.edu:
AS Q1. say you send an INVITE and you get a 302 response with
AS Contact: sip:[EMAIL PROTECTED];sdfs=sd;msdf=21342;shabba=dabba
AS When you send the redirected INVITE (the
Hello Attila,
I think the answer for Q1 is
INVITE sip:[EMAIL PROTECTED] SIP/2.0
According to RFC the answer for Q2 is
The target specified by the Contact in the 302
/Sreenath
- Original Message
From: Igor Vanin [EMAIL PROTECTED]
To: Attila Sipos [EMAIL PROTECTED];
21 matches
Mail list logo
