from rfc 2796, sec 2 and sec 1 as below.
>From Sec 2
"The INFO method is not used to change the state of SIP calls, nor does it
change the state of sessions initiated by SIP. Rather, it provides
additional optional information which can further enhance the application
using SIP."
>From Sec 1
"
Thanks.
Please correct me if I am wrong, I guess INFO messages could also be used
for the same.
Regards,
Sunil
-Original Message-
From: shyam [mailto:shya...@huawei.com]
Sent: Friday, May 21, 2010 11:48 AM
To: 'Sunil Bhagat'; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-imp
To update dialog parameter viz. contact or to update session parameters such
as 'sessiontimer' etc.
***
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the per
Hi,
UPDATE without SDP has many use cases. Couple of them are
1) It acts as session refresh if session-refresh parameter are present
2) IF the caller or callee want to change the contact after the dialog is
established using UPDATE method you can change the same.
Thanks,
shyam
Hi All,
I have a small query regarding UPDATE method.
UPDATE method is used to change the session parameters. I wanted to know,
what is the use of sending UPDATE without any sdp.
Thanks,
Sunil
___
Sip-implementors mailing list
Sip-implementors
20 maj 2010 kl. 17.52 skrev Bob Penfield:
> I agree with Robert. B2BUAs should decrement Max-Forwards when they are
> forwarding requests like a proxy does. I think the only case in which they
> might reset it would be a situation like a PBX where it is originating the
> call.
>
Right - so li
The question was the response and the response is 400-bad request.
Now , based on first or second callid . I think it works like VIA/ROUTE ,
normally the first VIA/RPUTE must be used. Then I think the first CALLID-ID
will be enough JUST to TELL to the client
that there is a bad REQUEST an
The RFC4475 fails to indicate which Call-Id to place within the 400 response. :)
Some requests are too malformed to bother returning a 400 response. Some
vendors feel that a duplicated or missing Call-ID falls into that category;
other vendors will return a 400 (even if the 400 is also malforme
Olle,
On Thu, May 20, 2010 at 3:51 PM, Olle E. Johansson wrote:
> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01
> The BCP draft clearly says that B2BUA's should RESET the Max-Forwards header.
I believe this is a bug, see
http://www.ietf.org/mail-archive/web/speermint/current/msg02608.
RFC4475 -->Session Initiation Protocol (SIP) Torture Test Messages
3.3.8. Multiple Values in Single Value Required Fields
The message contains a request with multiple Call-ID, To, From, Max-
Forwards, and CSeq values. An element receiving this request must
not break.
An ele
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Olle E. Johansson
[regis...@webway.se]
Here at SIPit we had a test involving B2BUA's in spirals and loops and other
dangerous situations.
Hi,
There is nothing like two callids, It is a unique identifier for the
call-leg/session. Hence it should match with the request callid.
Regards,
Satyakumar
- Original Message -
From: "RAVI KUMAR"
To: "Iñaki Baz Castillo"
Cc:
Sent: Thursday, May 20, 2010 12:08 AM
Subject: Re:
On Thursday 20 May 2010 06:20:39 Vivek Batra wrote:
> Once the port has been resolved with DNS SRV, do we need to place the
> resolved port in URI before sending SIP message to the UAS? Or can we kept
> the port field blank?
> One more point, do we need to use the SRV domain (SIP domain for which
RFC 3263 clearly states
The procedures defined here
in no way affect this URI (i.e., the URI is not rewritten with the
result of the DNS lookup), they only result in an IP address, port
and transport protocol where the request can be sent.
i.e The DNS results must be used to directly set
I agree with Robert. B2BUAs should decrement Max-Forwards when they are
forwarding requests like a proxy does. I think the only case in which they
might reset it would be a situation like a PBX where it is originating the call.
cheers,
(-:bob
-Original Message-
From: sip-implementors
Here at SIPit we had a test involving B2BUA's in spirals and loops and other
dangerous situations.
Robert Sparks and I ended up with a discussion about how B2BUA's should handle
Max-Forwards.
http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01
The BCP draft clearly says that B2BUA's should
Sorry, ignore my last mail, my mistake. I again put my query below;
sip:FQDN;transport=x -> Resolve x by DNS SRV If successful, resolve by DNS
A and send to the resolved ip address and resolved port, over transport x
If non-successful, resolve by DNS A and send to the resolved ip address,
por
Hi Victor,
Thanks for your comments. I have issue with the following URI format;
sip:FQDN;transport=x -> Resolve x by DNS SRV If successful, resolve by
DNS A and send to the resolved ip address and resolved port, over
transport x If non-successful, resolve by DNS A and send to the
resolved
Thanks for your response!
I understand call-Id should be unique for one call and 4xx should be proper
response. Does any sip rfc mention what ideally we should do if we get two
different call-id.
rgds,
Ravi
On 5/19/10, Iñaki Baz Castillo wrote:
>
> 2010/5/19 RAVI KUMAR :
>
> > Now my questi
You may be interested in RFC 5393 too
http://tools.ietf.org/html/rfc5393
On Thu, May 20, 2010 at 7:41 PM, Pandurangan R S
wrote:
> This is a known bug against RFC3261.
>
> http://bugs.sipit.net/show_bug.cgi?id=648
>
> On Thu, May 20, 2010 at 6:31 PM, Aaron Clauson wrote:
>> I have a problem und
This is a known bug against RFC3261.
http://bugs.sipit.net/show_bug.cgi?id=648
On Thu, May 20, 2010 at 6:31 PM, Aaron Clauson wrote:
> I have a problem understanding how RFC3261 would allow loop detection for a
> request that was bouncing between two or more proxies.
>
> Section 16.6.8 states:
>
I have a problem understanding how RFC3261 would allow loop detection for a
request that was bouncing between two or more proxies.
Section 16.6.8 states:
"Loop detection is performed by verifying that, when a request
returns to a proxy, those fields having an impact on the
processing of the requ
22 matches
Mail list logo
