<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors">
    <title>gmane.ietf.sip-implementors</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22365"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22364"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22363"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22362"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22361"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22360"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22359"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22358"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22357"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22356"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22355"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22354"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22353"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22352"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22351"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22350"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22349"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22348"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22347"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22346"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22365">
    <title>Re: ports renegociation - Email found in subject</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22365</link>
    <description>&lt;pre&gt;"Yes; it is possible.  It can occur anytime a device wants to do it."

RFC 3261 section 14:

"This section describes how to modify the actual
   session.  This modification can involve changing addresses or ports,
   adding a media stream, deleting a media stream, and so on.  This is
   accomplished by sending a new INVITE request within the same dialog
   that established the session.  An INVITE request sent within an
   existing dialog is known as a re-INVITE.

      Note that a single re-INVITE can modify the dialog and the
      parameters of the session at the same time.

   Either the caller or callee can modify an existing session.

   The behavior of a UA on detection of media failure is a matter of
   local policy.  However, automated generation of re-INVITE or BYE is
   NOT RECOMMENDED to avoid flooding the network with traffic when there
   is congestion."

From: ikuzar RABE [mailto:ikuzar9295&amp;lt; at &amp;gt;gmail.com]
Sent: Wednesday, June 19, 2013 5:26 AM
To: Brett Tate
Cc: sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.e&lt;/pre&gt;</description>
    <dc:creator>Brett Tate</dc:creator>
    <dc:date>2013-06-19T11:18:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22364">
    <title>Re: ports renegociation - Email found in subject</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22364</link>
    <description>&lt;pre&gt;Ok, thanks.
I was not clear enough.
I'd like to know if there can be a port (or IP and port) renegotiation
between two UAs which are directly linked (without another SIP
proxy/server, without SIP entity between both) while RTP flow is already
established.






2013/6/18 Brett Tate &amp;lt;brett&amp;lt; at &amp;gt;broadsoft.com&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>ikuzar RABE</dc:creator>
    <dc:date>2013-06-19T09:25:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22363">
    <title>About REGISTRAR forwarding request to UACsupporting RFC5626</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22363</link>
    <description>&lt;pre&gt;Hi,

 

                I have doubt regarding REGISTRAR forwarding request to UAC
which supports RFC5626.

 

According to RFC5626, Outbound Edge Proxy will add Path header in REGISTER
message sent to REGISTRAR, this will ensure

that REGISTRAR will send incoming calls to Edge Proxy first. My doubt is,
How does REGISTRAR know about the IP and Port of Edge proxy

where request has to be forwarded. The Path header sent by Edge proxy
contains Flow Token which is string, so does REGISTRAR store the

Via information for further requests(not correct according to RFC3261) or
stores the transport layer IP and Port ?

 

I would highly appreciate if you can share your views how it is implemented.

 

This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other&lt;/pre&gt;</description>
    <dc:creator>krishna</dc:creator>
    <dc:date>2013-06-19T02:59:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22362">
    <title>Re: ports renegociation - Email found in subject</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22362</link>
    <description>&lt;pre&gt;Party A is connected to party B through B2BUA.  For instance, see RFC 3725 diagrams and assume Controller is a B2BUA.

The B2BUA sends re-INVITE to party A  over the existing dialog (such as within RFC 3725 figure 8) when stimulated to connect party A to party C.


From: ikuzar RABE [mailto:ikuzar9295&amp;lt; at &amp;gt;gmail.com]
Sent: Tuesday, June 18, 2013 11:36 AM
To: Johan DE CLERCQ
Cc: Brett Tate; sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
Subject: Re: [Sip-implementors] ports renegociation - Email found in subject

Brett, what do you mean with " when reconnecting A from B to C using the same dialog between A and B2BUA."
What is A, B, C ?

2013/6/18 Johan DE CLERCQ &amp;lt;j.declercq&amp;lt; at &amp;gt;vocalcom.be&amp;lt;mailto:j.declercq&amp;lt; at &amp;gt;vocalcom.be&amp;gt;&amp;gt;
it also happens on call transfers.

-----Original Message-----
From: Brett Tate [mailto:brett&amp;lt; at &amp;gt;broadsoft.com&amp;lt;mailto:brett&amp;lt; at &amp;gt;broadsoft.com&amp;gt;]
Sent: dinsdag 18 juni 2013 14:14
To: ikuzar RABE; sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu&amp;lt;mailto:sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu&amp;gt;
Subject: Re: [Sip-implementors] ports&lt;/pre&gt;</description>
    <dc:creator>Brett Tate</dc:creator>
    <dc:date>2013-06-18T16:05:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22361">
    <title>Re: ports renegociation - Email found in subject</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22361</link>
    <description>&lt;pre&gt;Brett, what do you mean with *"* when reconnecting A from B to C using the
same dialog between A and B2BUA."
What is A, B, C ?


2013/6/18 Johan DE CLERCQ &amp;lt;j.declercq&amp;lt; at &amp;gt;vocalcom.be&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>ikuzar RABE</dc:creator>
    <dc:date>2013-06-18T15:35:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22360">
    <title>Re: ports renegociation - Email found in subject</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22360</link>
    <description>&lt;pre&gt;it also happens on call transfers. 

-----Original Message-----
From: Brett Tate [mailto:brett&amp;lt; at &amp;gt;broadsoft.com] 
Sent: dinsdag 18 juni 2013 14:14
To: ikuzar RABE; sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
Subject: Re: [Sip-implementors] ports renegociation - Email found in subject

Yes; it is possible.  It can occur anytime a device wants to do it.  Some B2BUAs will do it (change both ip-address and port) when reconnecting A from B to C using the same dialog between A and B2BUA.


_______________________________________________
Sip-implementors mailing list
Sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3345 / Virus Database: 3199/6419 - Release Date: 06/17/13

&lt;/pre&gt;</description>
    <dc:creator>Johan DE CLERCQ</dc:creator>
    <dc:date>2013-06-18T13:57:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22359">
    <title>Re: ports renegociation</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22359</link>
    <description>&lt;pre&gt;Yes; it is possible.  It can occur anytime a device wants to do it.  Some B2BUAs will do it (change both ip-address and port) when reconnecting A from B to C using the same dialog between A and B2BUA.


&lt;/pre&gt;</description>
    <dc:creator>Brett Tate</dc:creator>
    <dc:date>2013-06-18T12:14:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22358">
    <title>Re: ports renegociation</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22358</link>
    <description>&lt;pre&gt;Nobody has an idea ... ??


2013/6/11 ikuzar RABE &amp;lt;ikuzar9295&amp;lt; at &amp;gt;gmail.com&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>ikuzar RABE</dc:creator>
    <dc:date>2013-06-18T12:00:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22357">
    <title>Re: max length</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22357</link>
    <description>&lt;pre&gt;There is no limit.

On 6/17/13 11:24 AM, Mahudeswaran A wrote:

&lt;/pre&gt;</description>
    <dc:creator>Paul Kyzivat</dc:creator>
    <dc:date>2013-06-17T15:36:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22356">
    <title>max length</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22356</link>
    <description>&lt;pre&gt;Hi,
Would like to know what's is the max length for sip headers FROM, TO

Regards
Mahu

&lt;/pre&gt;</description>
    <dc:creator>Mahudeswaran A</dc:creator>
    <dc:date>2013-06-17T15:24:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22355">
    <title>Re: IPv4 to IPv6 interworking issue</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22355</link>
    <description>&lt;pre&gt;Hi All,
I have a doubt on ipv4 to ipv6 interwoking. A party (ipv4) with sdp parameter b=AS: X call to B party (ipv6).Is it necessary to change sdp parameter b=AS: X for ipv4 to ipv6 interworking. If yes then is it the responsibility of B2BUA to change this parameter. We are using B2BUA for ipv4 to ipv6 interwoking.
Can anyone please suggest??
Thanks in advance.       
&lt;/pre&gt;</description>
    <dc:creator>Tamjid Ali</dc:creator>
    <dc:date>2013-06-15T15:18:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22354">
    <title>Re: Address change in "Via" field from private IP to public IP.</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22354</link>
    <description>&lt;pre&gt;
I'm not aware of an RFC recommending the indicated behavior; however there are some benefits of such behavior.  It prevents the UAS from uselessly attempting (per RFC 3263 section 5) the private address upon error sending to the received location.  It improves the RFC 3261 section 17.2.3 transaction matching since there might be multiple devices supplying the same private address within Via sent-by.

RFC 3581 discusses updating the Contact although other things would also be updated as needed.


&lt;/pre&gt;</description>
    <dc:creator>Brett Tate</dc:creator>
    <dc:date>2013-06-14T09:53:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22353">
    <title>Re: Address change in "Via" field from private IP topublic IP.</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22353</link>
    <description>&lt;pre&gt;This is interesting Somesh,  maybe such a mechanism is involved after all. I wouldn't read much into the second REGISTER part as now I observe all the new REGISTERs going out with the public IP address.

Thank you so much for highlighting that, I will check if STUN (or a similar mechanism) is in place for the client to be aware of the public IP.

What if such a mechanism was not there , would I face problems ? The sip client (un aware of the public IP address) would send out REGISTER having my laptop's private IP in the contact &amp;amp; via headers - but I am sure some other device along the way would do the honours - I am just not sure which.

I am actually not facing any issues with this. I am having trouble with a PBX that I have which does not seem to be "aware" &amp;amp; sends out a REGISTER with its private IP in contact &amp;amp; via. Calls do not land on my PBX subsequently from the outside, public networks.

Thanks again!

Gaurav Srivastava | Senior Systems Engineer
phone | +61.449642846 | Gaurav.Srivastava&amp;lt; at &amp;gt;inin.com
 
In&lt;/pre&gt;</description>
    <dc:creator>Srivastava, Gaurav</dc:creator>
    <dc:date>2013-06-14T06:58:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22352">
    <title>Re: Address change in "Via" field from private IP topublic IP.</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22352</link>
    <description>&lt;pre&gt;Hello Gaurav,

May be your sip client is learning the IP address (NAT) via some mechanism like STUN etc. But I am not sure, why it only does for second REGISTER. May be its designed that way that after learning, during re-REGISTRATIONs it will use the learnt address.

One more interesting point - are you facing any issues with this? May be your organization NAT is SIP aware?

Br,
Somesh

-----Original Message-----
From: ext Srivastava, Gaurav [mailto:Gaurav.Srivastava&amp;lt; at &amp;gt;inin.com] 
Sent: Wednesday, June 12, 2013 8:00 AM
To: SIP Implementors; discussion&amp;lt; at &amp;gt;sipforum.org
Subject: [Sip-implementors] Address change in "Via" field from private IP to public IP.

Hi,

I am using a SIP soft phone (Zopier) that registers to Skype. The softphone sends out a REGISTER message to sip.skype.com for this.

While going through the messaging, I noticed that initially the via field contains my private IP address.

When the client re REGISTERs, the address changes from my private IP to the public IP which my organization has.

Please&lt;/pre&gt;</description>
    <dc:creator>Shanbhag, Somesh (NSN - IN/Bangalore</dc:creator>
    <dc:date>2013-06-14T06:50:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22351">
    <title>Address change in "Via" field from private IP topublic IP.</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22351</link>
    <description>&lt;pre&gt;Hi,

I am using a SIP soft phone (Zopier) that registers to Skype. The softphone sends out a REGISTER message to sip.skype.com for this.

While going through the messaging, I noticed that initially the via field contains my private IP address.

When the client re REGISTERs, the address changes from my private IP to the public IP which my organization has.

Please note that I am running the packet capture on my laptop.

I am trying to understand the change in IP address - please let me know if you have an understanding of this.

Warm Regards,
Gaurav Srivastava.
&lt;/pre&gt;</description>
    <dc:creator>Srivastava, Gaurav</dc:creator>
    <dc:date>2013-06-12T02:30:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22350">
    <title>Re: contact header.</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22350</link>
    <description>&lt;pre&gt;
It doesn't *need* to, but in normal cases it would be expected.

The response to the register request is the set of contacts that are 
currently registered at the time the response is generated. Assuming you 
supplied a contact in the register request, with a non-zero expiration 
time, then you would expect that the response would contain that 
contact. If it *doesn't* contain the contact, then you must presume that 
you are not registered.

Thanks,
Paul

&lt;/pre&gt;</description>
    <dc:creator>Paul Kyzivat</dc:creator>
    <dc:date>2013-06-11T14:20:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22349">
    <title>contact header.</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22349</link>
    <description>&lt;pre&gt;Scenario :

uas registers to generic proxy (next hop).

As we all know, when the uas sends a register to a proxy the register request will have a contact header.
Upon the proxy returning 200 OK, does this  200 OK needs to have the same contact header ?

Cheers, Johan.
&lt;/pre&gt;</description>
    <dc:creator>Johan DE CLERCQ</dc:creator>
    <dc:date>2013-06-11T13:52:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22348">
    <title>ports renegociation</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22348</link>
    <description>&lt;pre&gt;Hi all,

I 'd like to know if  ports can be renegotiated (with a new INVITE for
example) while RTP flows are already established ... !
If it is possible, in which case we can face with this situation ?
(multicast ? other ?)

Thanks for your help
&lt;/pre&gt;</description>
    <dc:creator>ikuzar RABE</dc:creator>
    <dc:date>2013-06-11T13:28:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22347">
    <title>Re: CANCEL after 100 trying</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22347</link>
    <description>&lt;pre&gt;I agree; the CANCEL can be sent after receiving a 100 response.

The following are some additional snippets which define "provisional response" and why RFC 3261 introduced delaying CANCEL until 1xx received.

Section 6:

"Provisional Response: A response used by the server to indicate
   progress, but that does not terminate a SIP transaction.  1xx
   responses are provisional, other responses are considered
   final."

Section 7.2:

"any response with a status code between 100 and 199 is
 referred to as a "1xx response""

Section 28.1:

"A UA or proxy cannot send CANCEL for a transaction until it gets a
 provisional response for the request.  This was allowed in RFC
 2543 but leads to potential race conditions."



&lt;/pre&gt;</description>
    <dc:creator>Brett Tate</dc:creator>
    <dc:date>2013-06-11T09:47:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22346">
    <title>Re: CANCEL after 100 trying</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22346</link>
    <description>&lt;pre&gt;Hi Rupesh

RFC 3261 9.1 Client Behavior throws light on the expected behavior:

Excerpts:
If no provisional response has been received, the CANCEL request MUST
NOT be sent; rather, the client MUST wait for the arrival of a
provisional response before sending the request.

..
..

If it was allowed to send the CANCEL before receiving a response
for the previous request, the server could receive the CANCEL
before the original request.

Regards
Tarun Gupta
Aricent


-----Original Message-----
From: Rupesh Mothe [mailto:RM0063284&amp;lt; at &amp;gt;TechMahindra.com]
Sent: Monday, June 10, 2013 3:47 PM
To: Sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
Subject: [Sip-implementors] CANCEL after 100 trying

Can CANCEL be sent after receiving 100 trying? Here 100 trying doesn't transmitted from UAS





Thanks,

Rupesh Mothe |Tech Mahindra Ltd, Pune | Extn. 3671 | Cell No.
+91-9960727012






============================================================================================================================Disclaimer:  This message and&lt;/pre&gt;</description>
    <dc:creator>Tarun2 Gupta</dc:creator>
    <dc:date>2013-06-11T03:11:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22345">
    <title>Re: CANCEL after 100 trying</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22345</link>
    <description>&lt;pre&gt;The reason why the specs advice to not send a CANCEL if a 1xx is not 
received is because there is a big chance that the CANCEL will suffer 
the same fate as the INVITE - that is it will not get any response 
either.  This ought to save your implementation some unrequired work.  
However, there is really no harm done if you send a CANCEL regardless of 
whether you received a provisional response or not.

On 06/10/2013 06:17 PM, Rupesh Mothe wrote:

&lt;/pre&gt;</description>
    <dc:creator>Joegen Baclor</dc:creator>
    <dc:date>2013-06-11T02:45:29</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.ietf.sip-implementors">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.ietf.sip-implementors</link>
  </textinput>
</rdf:RDF>
