In your flow, 4th step seems to be incorrect.
It is true that P2 remembers the Session-Expires that it has
examined/modified in the request, but it will not insert
session-expires in 2xx response because the request did not have
"supported: timer" when it was processed by P2 (indicating that UAC
d
All that I
can agree to is "a proxy should not implement session expiration
procedures if neither of the UAC or UAS supports RFC 4028".
1. But as elaborated in the below mentioned scenario, P1 assumes that
UAS would support RFC 4028 and it puts Session-Expiration header and
Min-SE header in ini
Hi Dushyant,
This is not a bug or understanding problem, we also thought the same way,
but this is specified only for the proxies which explicitly needs this
feature, In such a case they can establish it, Also this will be very
specific to the few scenarios where the traffic is too high so that
Hi All
I have a query regarding the ISUP disposition handling in the INVITE
message with encapsulated ISUP.
If a ingress SIP-I trunk group receives an INVITE with ISUP encapsulated
and ISUP disposition handling = 'required', can the egress SIP-I trunk
change this to 'optional'?
Why would that merit the response "FAIL?"
Attila Sipos wrote:
> At risk of getting a FAIL from Mr.Balashov, does
> anyone know anything about MS Outlook 2003 support for In-Reply-To?
>
> how to enable it?
>
>
>
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbi
Hi all,
If I have UAC who is sending a REGISTER request trough proxy server.
Proxy server sends this request further on to REGISTER server.
REGISTER server sends a Redirect response to the proxy server.
Now, should proxy server send this Redirect response to UAC, or should
it try to send the REGI
At risk of getting a FAIL from Mr.Balashov, does
anyone know anything about MS Outlook 2003 support for In-Reply-To?
how to enable it?
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Ba
Hi Attila, could I suggest you to use a mail client which respects and
implements the "In-Reply-To" header? Then when you reply in a thread your mail
would include such header and would appear in the corresponding thread in any
other RFC complian mail client.
For now, every mail from you is a n
> That essentially means neither UAC nor UAS supports RFC 4028 but P1 and P2
> run the session expiration timers as a result when the timer times out both
> P1 and P2 release their calls/ resources.
This is not expected to occur as per RFC 4028. May be you should just
elaborate how you think situa
>>UA needs to know and publish its public IP address/port.
this is true in some cases. If you are a standalone UA
(not using a SIP server) and want to receive requests,
then rport is not good enough. (but of course, you still need
an external STUN server)
In other cases, a SIP server (with whi
_
__ _ _
| UAC | __ | P1 | ___ | P2 | ___ | UAS |
|_| |__| |_| |_|
Consider the above configuration -
UAC
doesn't insert Session-Expires header in Initial INVITE
Attila,
[Attila] - "rport is a very simple mechanism without very low overhead for
achieving simple NAT traversal without requiring a separate protocol such as
STUN which requires a STUN client and STUN server"
[Vivek] - Even rport is used, I think STUN mechanism will still be required
since rpor
>>So, does implementing 'rport' will add value to my SIP Stack core?
1. It might be useful for a SIP receiving server to know that you
support rport (but this is arguable)
If it knows you support rport, it can then safely send responses
back on the "source port".
(For best interop anyway
Hi Keerthi,
rport is used to put infomation in sip message itself ,if some nat is in
between two sip entities.
If you doesn't want to keep some transaction state information for each
request received ,
it's the used to send response accross nat.
note: rport is supported by all sip stacks I have w
Hi Attila,
Firsly thanks for your response; in my current setup, the
application using my SIP Stack has the support of STUN client.
As per my current info, STUN supports for 3 types of NAT's (i.e. Full Cone,
Restricted Address Cone and Port restricted Cone NATs) and it does not s
El Martes, 24 de Noviembre de 2009, KEERTHI KUMAR escribió:
> Hi All,
> Myself Keerthi Kumar, currently planning to implement 'rport'
> support in the SIP Stack using RFC 3581. But, now i am stuk at finding a
> Valid use case that 'rport' solves and leads over STUN or other NAT
> traver
Attila is correct. rport is just a fancy way of saying that replies
should be sent to the source port whence the request came, which is
exactly how stateful connection tracking works in conventional source
NAT gateway implementations.
Attila Sipos wrote:
> STUN doesn't work for all NAT types,
STUN doesn't work for all NAT types, I believe rport does.
rport is a very simple mechanism without very low overhead for achieving
simple NAT traversal without requiring a separate protocol such as STUN
which requires a STUN client and STUN server.
rport's use cases are not unique but for UDP SI
Hi All,
Myself Keerthi Kumar, currently planning to implement 'rport' support
in the SIP Stack using RFC 3581. But, now i am stuk at finding a Valid use case
that 'rport' solves and leads over STUN or other NAT traversal techniques.
So, i request you to please suggest me few use cases
19 matches
Mail list logo
