Hi,
After analysing the message, I guess the message is spiralled in the
proxy. Since the 2 branch are different inserted by proxy, I came to such
conclusion.
Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bK0ceb.85584e86.0
Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bK0ceb.75584e86.0
Via:
Hi,
Fig was missing in the previous mail. Sorry for inconvience.
Manju
-Original Message-
From: Manjunath Warad [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 01, 2006 2:35 PM
To: 'Anshuman Rawat'; 'sip-implementors@cs.columbia.edu'
Subject: RE: [Sip-implementors]
Hi,
This behavior is only noticed in 1 direction i.e. for calls from IP
phone A to Cisco 7960.
It never happens for calls from Cisco phone to IP phone A. I have the
INVITEs pasted here. In the 2nd INVITE, we can see that there are 2
distinct VIA headers and only 1 Record-Route value.
Hi Rhys,
I think that you could use the RPID schema without actually using it in
the same way that data model is defining the presence data model.
Presence model (07 - approved as RFC) says:
This document defines the underlying presence data model used by
Session Initiation Protocol
Hi,
As I noticed the message, the problem lies in the message from the IP
phone A. If you could see the INVITE message from IP phone A, it has ROUTE
header, but in case of INVITE message from Cisco, there is no ROUTE
header. Both the SIP phones will forward the request to the pre-configured
Hello Rhys,
We currently have published RPPID / GeoPriv API for GooGaYa.
Let us know if you want to have interoperability tests between the two.
-E
Avshalom Houri wrote:
Hi Rhys,
I think that you could use the RPID schema without actually using it in
the same way that data model is defining
Hi,
I was wondering what should be done in the following case:
when a UAC receives a 200 OK to an INVITE request with no Record-Route
header, and a Contact header like this:
sip:[EMAIL PROTECTED]:5060;transport=UDP
According to RFC 3261 (section 12.2.1.1), the UAC must place the remote
target
For the handling of NAPTR query result, RFC3263 section 4.1 says A client
resolving a SIP URI should retain (NAPTR) records with SIPS protocol, if
the client support TLS.
Assume the following conditions when a client performs NAPTR query:
- the result of NAPTR query indicates TLS/TCP/UDP all
On Wed, 2006-02-01 at 16:22 +0100, Sigrid Thijs wrote:
According to RFC 3261 (section 12.2.1.1), the UAC must place the remote
target URI into the Request-URI if the route set is empty.
Is it allowed to send an ACK with a Request-URI like this:
ACK sip:[EMAIL PROTECTED]:5060;transport=UDP
Hi,
How are you guys doing? I have tried to answer your queries ... the
answers are inline.
Best regards,
Harpreet Juneja
--- Karnam, Swamy [EMAIL PROTECTED] wrote:
Hi,
Has anyone implemented a SIP app that uses the Digest algorithm
with
qop=auth-int ?
in RFC 2617 A2 is defined
A dialog is established and a reINVITE is sent. The 200 ok response for
the reINVITE contains Record-Route header. Is the UAC supposed to
recompute the route set and how?
It seems that SIP RFC3261 is somewhat vague on this. The RFC section
13.2.2.4 says: If the dialog identifier in the 2xx
Hey Harpreet,
Thanks for the info. The new line explains the md5sum difference.
The draft example is correct (and so is the md5sum output) my perl
module
was stripping the new line off.
Thanks,
Swam
-Original Message-
From: Harpreet Juneja [mailto:[EMAIL PROTECTED]
Sent:
On Wed, 2006-02-01 at 14:33 -0500, Romel Khan wrote:
A dialog is established and a reINVITE is sent. The 200 ok response for
the reINVITE contains Record-Route header. Is the UAC supposed to
recompute the route set and how?
It seems that SIP RFC3261 is somewhat vague on this. The RFC section
Hi
Pls send me some documents thats only meant for Scurity purpose
deployed for SIP.
thanks
Kalan
-
Jiyo cricket on Yahoo! India cricket
___
Sip-implementors mailing list
14 matches
Mail list logo
