Hello and Happy New Year all sip-implementors!
We had an interesting question on the Asterisk developer mailing list last year.
Assume that a dialog was set up in an INVITE transaction between two UAs and a
proxy in between. The proxy added a record-route so the two UAs now has a route
set
I think B party must terminate with 400 Invalid Request and send BYE to the
existing dialog. It might be someone is snooping as well in the network.
-Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu]
2011/1/4 Olle E. Johansson o...@edvina.net:
Now one UA sends a SIP request directly between the UA's instead of following
the route set for the dialog.
- Should this request be dropped?
- Should it be accepted and processed?
- Shout it be responded to with an error message - if so, which
Hi All,
is there any SIP soft phone and application server supported with MSRP?
other than BLINK.
any response is highly appreciated!!
Thanks
Sudhir
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
Hi ,
Thanks for the responses. Even I thougt the same.
Lets say for the same case mean for unholding the call , if we get Re-inivte
with no SDp from B2BuA . How SIP entity should respond ( SIP entity is in Held
state).
Does SIP entity should respond with the Current state with 200 ok
Hi All,
with in the same session, playing announcements is not allowed. There could
be only on dialog established between UAC and UAS1(to_tag1). But there could
be multiple dialogs established @ UAC due to UAS1, UAS2, but not by the
same UAS. Sending diferent SDPs in multiple 1xx messages
We should proceed with option-1. In this case Re-Invite with out SDP leads
to delayed media negotiation...
On Tue, Jan 4, 2011 at 6:36 PM, Chandan Kumar chandan_28...@yahoo.comwrote:
Hi ,
Thanks for the responses. Even I thougt the same.
Lets say for the same case mean for unholding the
For Android: http://code.google.com/p/imsdroid/
For Windows: http://code.google.com/p/boghe/
--- En date de : Mar 4.1.11, voice freak t.sudhirku...@gmail.com a écrit :
De: voice freak t.sudhirku...@gmail.com
Objet: [Sip-implementors] any SIP soft-phone supported with MSRP??
À:
my idea is to omit the port number from all the From header
in outbound SIP request. Do you think this will be problematic?
As others have indicated, RFC 3261 indicates that port within To/From are not
allowed and SHOULD be ignored. Because RFC 2543 allowed port within To/From,
it might be
2011/1/4 Brett Tate br...@broadsoft.com:
I'm not sure how the SIP working group intended RFC 3261 section 19.1 Table 1
paragraph indicating SHOULD ignore any disallowed components to apply to
section 19.1.4's URI comparison rules.
Fuly unclear. We could give our opinnion here, and any other
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Olle E. Johansson
[...@edvina.net]
Now one UA sends a SIP request directly between the UA's instead of following
the route set for the
2011/1/4 Worley, Dale R (Dale) dwor...@avaya.com:
I am surprised that any UA performs the checks necessary to determine that
this has happened. But if it discovers the problem, it should log it
somewhere for human interpretation.
Humm, I cannot imagine how a IMS mobile can warn my mother
Its not really a responsibility of the recipient to check this, at least
in straightforward cases. How would it know that the proxy has been
bypassed? If the request arrives, and has the correct form, then I would
expect the UAS to process the request. To detect the problem it would
have to
Look at the offeranswer draft for a discussion of this.
While your option 1 will work in some cases, it won't always work.
Specifically, if both sides put the call on hold, then there will be no
way to get off hold.
The solution is to always offer the directionality your end wants,
without
IMO, if a UA is given a URI to call, it generally has no business
messing with it in any way. Removing the port is altering the URI, and
should only be done by something in the domain of the URI that is
familiar with the policies for construction of URIs within that domain.
If the UA is
On 01/04/2011 03:30 PM, Paul Kyzivat wrote:
IMO, if a UA is given a URI to call, it generally has no business
messing with it in any way. Removing the port is altering the URI, and
should only be done by something in the domain of the URI that is
familiar with the policies for construction of
Hello,
The SIP recommendation tell us that the port must be present if it is not a
default port (5060).
INVITE sip:atcavolt...@10.48.6.189:1872;tgrp=CGR01REM;trunk-context=volte.com
SIP/2.0
To:sip:atcavolt...@volte.com
2011/1/5 Pavesi, Valdemar (NSN - US/Irving) valdemar.pav...@nsn.com:
Maybe the port (from ,to) can help to build the history of the call.
If you remove , it tell me that UA had used the default port 5060 to
originated the call , and it is not TRUE.
Why should the UAC set as From URI port the
Hi all,
Does any body know about SIP Soft Phone that supports IPSec?
Thanks,
Bharat
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
That's like asking if there is a SIP softphone that supports Ethernet.
Go learn your OSI burrito. IPSec operates at a different layer of
abstraction in the protocol stack than a VoIP application. It would
not be IPSec-aware if used with IPSec. In that sense, all softphones
support IPSec.
Hey Alex,
I know IPSec operates on different layers of protocol stack. But
I am looking for any SIP soft phone that supports Headers for SIP Security. RFC
3329.
So if any phone supports IPSec, should support the SIP Headers required for
establishing Security Associations using
Hi Nataraju,
Thanks for your inputs.
Sending different SDPs in multiple 1xx messages might be violating the
offer-answer model,
but if the first announcement is through reliable-1xx response and the
subsequent announcement is with UPDATE, then I guess it should be technically
right.
Correct me
On 01/04/2011 09:52 PM, Bharat S wrote:
Hey Alex,
I know IPSec operates on different layers of protocol stack. But I am
looking for any SIP soft phone that supports Headers for SIP Security.
RFC 3329.
So if any phone supports IPSec, should support the SIP Headers
required for establishing
23 matches
Mail list logo
