onsip / sip.js Goto Github PK

This was requested in the mailing list.

When receiving a REFER, the SIP.js user agent replies with a NOTIFY request immediately terminating the subscription. This is valid as per RFC 3515 Section 2.4.4, but more complete information (see section 2.4.5 of the RFC) would be nice.

There are a couple of places where SIP.js refuses to participate in sessions unless WebRTC-related global variables exist. However, thanks to the flexibility offered by the mediaHandlerFactory UA configuration option, it's possible to make calls using SIP.js in environments that don't have those variables.

Unfortunately, doing so currently requires an ugly workaround. We should find a way to make this unnecessary, perhaps by moving the WebRTC.isSupported logic into the WebRTC.MediaHandler.

I am currently considering to replace JsSIP in an existing application with SIP.js, and noticed that the terminate() method is missing from the documentation. It seemed extremely weird that API users have to manually keep track of the call state and call bye(), cancel(), etc. depending on the tracked call state when I want to end a call.

The source code of Session.js shows that terminate() does exist, so why is it not documented?

SIP/2.0 500 Server Internal Error
Via: SIP/2.0/WSS 192.168.10.242:7443;branch=z9hG4bK1gUp4XX93gp7m
To: "FreeSWITCH User" sip:[email protected];tag=f52hrsp0b3
From: sip:[email protected];tag=p8Nj7v7rHgNjF
Call-ID: h16h3jltrak4l04uso0k
CSeq: 60668795 INVITE
Supported: outbound
Content-Length: 0

Using git rev ec38b51 built myself.

Also shouldn't it say 'Internal Server Error'? LOL

Hi Guys. Just doing some testing on the new 0.6.0 release. Have found one minor issue:

When I accept a call with video: false, my webcam light is coming on as if Video is actually active. It did not do this on the 0.5.0 branch.

Here is the code i'm using to accept the call:

    session.accept({
        media: {
          audio: true,
          video: false,
          render: {
            remote: {
              audio: document.createElement('audio')
            }
          }
        }
      });

I read through RFC-3262 and I noted the following places where we might be out of compliance. Please correct me if I am wrong about these. I think most of them are on the UAS side.

Page 5 paragraph 1: 
   If a PRACK request is received by the UA core that does not match any
   unacknowledged reliable provisional response, the UAS MUST respond to
   the PRACK with a 481 response. 

I am pretty sure we are not checking if PACK's match outstanding reliable provisional responses.

Page 5 paragraph 2:
   If a reliable provisional response is retransmitted for 64*T1 seconds
   without reception of a corresponding PRACK, the UAS SHOULD reject the
   original request with a 5xx response.

I do not think that we handle this case at all. Though I feel it would definitely be an edge case because the transaction in general should time out before that timer is hit.

Currently, we ignore non-DTMF INFO requests. Applications such as FreeSWITCH send INFO packets in dialogs. We should acknowledge their receipt with a 200 Okay.

All tests done on the javascript console on Firefox 31 on Fedora 20 x86_64

<< SIP.Grammar.parse('presence.winfo', 'Event');

Object { event: "presence.,winfo" }

The "presence.,winfo" is incorrect. The returned value should be unchanged.

This bug breaks subscription to the "presence.winfo" event required to process remote presence watchers of current user.

For example, if dtmf is called twice in a row such that the second call occurs while the first tones are still queued, the second tones get added to the queue, but the first options are used when the second tones are actually played. The tone queue should contain options per tone instead of assuming a single options object applies to the entire queue.

When i try to use your example from http://sipjs.com/api/0.5.0/subscription/#events

i get

sip.ua | unable to add a listener to a nonexistent event notify sip-0.5.0.js:168
TypeError: Invalid or uninitialized event: notify
    at Object.EventEmitter.on (http://localhost:8080/js/sip-0.5.0.js:321:13)
    at new homeController (http://localhost:8080/app/controllers/homeController.js:6:19)

Greetings
Djcd

We already have the refer event, so let's get rid of referred. However, so applications don't have to reimplement the referred behavior, let's provide a SIP.Utils function they can register as a refer handler that will take care of it for them.

session.unmute() does not work

As it turns out, plugman publish doesn't work with plugins that have IDs with fewer than 3 components, like "com.sipjs":

plugman publish .
Invalid plugin ID. It has to follow the reverse domain `com.domain.plugin` format

To get around this, I tried publishing with an ID of "com.onsip.sipjs". This created the registry entry, but cordova plugin add com.onsip.sipjs still didn't work, because dist/sip.js wasn't among the files published:

cordova plugin add com.onsip.sipjs
Fetching plugin "com.onsip.sipjs" via plugin registry
Starting installation of "com.onsip.sipjs" for android
Preparing android project
Error: ENOENT, no such file or directory '/Users/josephfrazier/sipjs-cordova/plugins/com.onsip.sipjs/dist/sip.js'

Since plugman is based on npm, .npmignore containing dist/* prevents dist/sip.js from being published, despite the fact that plugin.xml specifies dist/sip.js as the plugin's JS module.

Assuming we keep the "com.onsip.sipjs" name, there are at least 4 solutions here (listed in order of personal preference):

1. Use src/SIP.js as the plugin's JS module, because we shouldn't be requireing bundled modules in the first place. See https://github.com/onsip/SIP.js/blob/0.6.2/plugin.xml#L4-L7
2. Fix plugman to publish files required by plugin.xml
3. After each release, do solution 4, but plugman publish . without committing the changes. I did this for 0.6.2, so I know it works, but it is another manual step in the release process.
4. Stop .npmignoreing dist/sip.js. This is ugly because we shouldn't be requireing bundled modules in the first place.

Rel100 behavior set on the UA is currently inconsistent, it currently only affects SIP.js client context. It does not affect behavior for SIP.js in a server context. Separately rel100 is set on the progress method when SIP.js is a server context.

I propose changing the default behavior when rel100 is set on the UA to the following (the defaults can all be overridden using the current parameter on the progress method):

Steps to reproduce

1. Create a new UA and register the configured extension
2. Send an invite to a contact
3. hang up (either by terminating the call from the remote end, or by sending bye or cancel)
4. Send another invite to the same contact with the same UA instance

The call fails and the server responds with SIP 400 Bad Content-Type Header.
By analyzing the diff between the INVITE of the first call and the INVITE of the second call, I've seen that in the second call there are the following differences:

• Proxy-Authorization header is not present
• Contact, Allow and Content-Type headers are repeated twice (see the snippet)

INVITE sip:contact@ip_address SIP/2.0
Via: SIP/2.0/WS 15r2vhc7cgv6.invalid;branch=z9hG4bK4810397
Max-Forwards: 70
To: <sip:contact@ip_address>
From: "WebCall" <sip:webcall@ip_address>;tag=jupd5unhqk
Call-ID: 17tklilbalv3fgmvj8np
CSeq: 7686 INVITE
Contact: <sip:[email protected];transport=ws;ob>
Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE
Content-Type: application/sdp
Contact: <sip:[email protected];transport=ws;ob>
Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE
Content-Type: application/sdp
Supported: outbound
User-Agent: testapp
Content-Length: 1351

My setup is:

• SIP.js 0.5 devel with last git revision (29f5fbb)
• FreeSWITCH 1.5.11 last git revision to date, compiled from source on a public IP address, using port 5066 for web socket

Proposed API:

/** Declaring DataChannel support **/
mediaHint.dataChannel = true; // Regardless of mediaHint being constraints or stream.
MediaHandler.getDescription(success, failure, mediaHint);

/** Learning about a new dataChannel (both sides fire this) **/
MediaHandler.on('dataChannel', function (dc) {
  dc.onmessage = ... // Your datachannel code. No abstraction beyond the native API.
});

/** Also stored on MediaHandler for convenience **/
if (MediaHandler.dataChannel) {
  MediaHandler.dataChannel.send('foo');
}

I think that's all there is to it. Most of the code is already living on my personal fork.

This issue was brought up on the mailing list.

UACs and UASs provide different arguments to the accepted event, as do INVITE vs non-INVITE contexts. They should be normalized to the following:

this.on('accepted', function (response, cause) { ... });

...where response is a SIP.IncomingMessage (for UAC) or String (for UAS), and where cause is a string reason phrase (such as one of SIP.C.REASON_PHRASE).

To get this information, the InviteServerContext would need to either save its 200 response until after it receives the ACK, or fire the accepted event when it sends the 200. I prefer the latter, as it matches more cleanly with RFC 3261 13.3.1.4. This has potential side effects on INVITEs without SDP, as the accepted event would be triggered before the SDP answer is received. I'd argue that this isn't a bad thing, as that feels like a different event.

I'll put a potential patch up here soon, but it should have some review before being pulled into master.

Okay, here goes... We've been putting this one off for too long.

Background

Since the beginning of time, there has been a desire for media and WebRTC-related events. Ever since the first GetUserMedia call succeeded asynchronously, ever since calls were accepted before ICE completed, ever since the other day when we mixed up the accepted event just a little bit...media events have been on the horizon. At first, they were impossible (or just plain hard), as the media and the signaling were mixed in one Session constructor.

Now, we have separated the media from the signaling, leaving a completely eventless MediaHandler class just waiting for this functionality.

The Goal

Let's figure out what events we want, and try to define their behavior and naming in a way that is consistent.

Requested Events So Far

• Upon callback of successful getUserMedia call (Should we also lump in 'beginning to ask for getUserMedia,' so UIs can be updated with big arrows and orange bars?)
• Upon beginning ICE candidate collection
• Upon completing ICE candidate collection and sending of INVITE.
• Upon receipt of offer. (Independent of INVITE w/o SDP)
• Upon receipt of answer. (INVITE w/o SDP causes this to happen later than accepted) (See issue #20)
• Any that I missed?

I'm also going to combine the following into this discussion, as it is a related feature:

• Upon DataChannel created/opened/closed/error
• Upon DataChannel message received.

Also, remember that all of these events apply only to stock WebRTC MediaHandlers. These events shouldn't be used internally by other parts of SIP.js, as a custom MediaHandler may not implement them.

PS - I know, I changed my mind about discussing this on the Issues tracker. I started typing this to the mailing list, but here does feel like a better place for development chatter. Sorry, Joseph. :-/

Dear all,

first of all, thanks for SIP.js - I switched from another library and yours is some much more comfortable 👍

I have two questions right now:

• How can I create a conference, meaning have a call with more than two participants
• Can user credentials used by more than one person at a time? For example, I want to store one generic user on a webpage, so that everybody who has this webpage open gets called and the first who answers should receive the call. Is that possible?

Thanks and best regards,
Chris

See #15 (comment) for the reasoning behind this.

According to RFC 6665 Section 4.1.2.2 (emphasis mine):

At any time before a subscription expires, the subscriber may refresh
the timer on such a subscription by sending another SUBSCRIBE request
on the same dialog as the existing subscription. The handling for
such a request is the same as for the initial creation of a
subscription except as described below.

However, a SIP.js Subscription refreshes itself by calling its subscribe method, as seen on lines 94 and 199 of Subscription.js. Since the subscribe method simply (re)sends the initial SUBSCRIBE request, it does not contain a To tag, but it should according to RFC 3261 Section 12.2.1.1 (emphasis mine):

The URI in the To field of the request MUST be set to the remote URI
from the dialog state. The tag in the To header field of the request
MUST be set to the remote tag of the dialog ID. The From URI of the
request MUST be set to the local URI from the dialog state. The tag
in the From header field of the request MUST be set to the local tag
of the dialog ID. If the value of the remote or local tags is null,
the tag parameter MUST be omitted from the To or From header fields,
respectively.

This can be demonstrated by using code from #86 to create a UA with traceSip:true, calling UA#subscribe with a small value for the expires option, and observing the resulting SUBSCRIBE requests. Notice that the refresh requests actually create separate subscriptions, which explains why they have different ids in Subscription#receiveResponse.

We can use map to cache the callbacks.

var arr = ['a', 'b', 'c', 'd', 'e'];
arr.map(function (value, i) {
    return function () {
        console.log(value);
        if (value === 'c') {
            arr.splice(i, 1);
        }
    };
}).forEach(function (f) {
    f()
});
console.log(arr)

When sending a REFER request, SIP.js emits 'refer' with the request. This emission does not have the uri before the request in the arguments passed to event listeners (unlike the 'refer' emitted when a REFER is received).

While it is convenient for the application to pass multiple different options to the Session, it greatly complicates the WebRTC.MediaHandler code to support multiple structures of mediaHint.

Cons:

• Code between the application and the Session needs to be aware of options related to media. This is already the case with the current optionsOverride mechanism.

Pros:

• Flexibility to add more custom parameters to the MediaHint without potentially conflicting with constraint or MediaStream properties.
• Simplify logic in the MediaHandler. (This is debatable, actually, as something will have to decide what to do if multiple conflicting options are specified.
• Avoid instanceof, which is a bad habit to get into anyways.

Proposed Syntax:

var mediaHint = {
  constraints: { audio: true, video: true }, // gUM constraints
  mediaStream: new MediaStream(), // Don't specify this *and* constraints
  dataChannel: true,
  remoteElement: myVideoElement,
  localElement: myOtherVideoElement
};

For custom hacks.

When using GRUU'd registrations, calls fail to set up. The INVITE and 200 go through properly, but the ACK uses the GRUU as the Request URI. When the UAS receives it, it does a basic check to see that the request is actually directed at it. The way it does this is fairly naive:

 if(request.ruri.user !== this.configuration.uri.user && request.ruri.user !== this.contact.uri.user) {
    this.logger.warn('Request-URI does not point to us');
...
}

That second part of the condition is meant to check against the contact, but it ignores the contact's GRUUs.

More discussion about this is on the mailing list here: https://groups.google.com/forum/#!topic/sip_js/uiaXS_qc2n8

JsSIP has "ended" for termination of an established call, and "failed" for termination of a non-established call.

SIP.js has "failed", "cancel" and "bye" (and "rejected", but I've ignored it since it is documented that the "failed" event is always triggered thereafter).

Are these events mutually exclusive? I have written a wrapper around the JsSIP class, and the "ended" and "failed" events provides me the required functionality to reliably implement a destructor that is called exactly once for a RTCSession.

Does SIP.js provide such guarantees? Are the failed/bye/cancel events mutually exclusive, and is exactly one of them going to be triggered regardless of whether the call is established? If so, please document this.

When setting rel100 on the UA currently you need to set a string. We should use our SIP.C.supported constants. This will ensure that the option is set correctly.

This will need to be backward compatible with our current rel100 UA options.

hi every body :-)

how can i send extra information in a Message !!
actually i send an extra headers ( in the object "options") but i can't receive it .. i even don't know if i send it correctly

please help :-)

For example: SIP.Grammar.parse("render;handling=optional", "Content_Disposition") currently returns {}, so we have to work around it like in 9b91437

I'm doing outgoing call. When destination side press 'reject' I recieve event 'accepted' with data.code '200'

I've heard of this happening a couple times, both in Chrome, across platform (once on Mac OS X and once on Windows 8.1).

sip.invitecontext.mediahandler | unable to acquire stream sip-0.5.0.js?v=1400985007312:168 NavigatorUserMediaError {constraintName: "", message: "", name: "PermissionDeniedError"} sip-0.5.0.js?v=1400985007312:170

It has been reported to happen more often when the JS Console is open, which suggests something weird may be going on.

Having a single handler per session (instead of a separate handler for each early dialog) provides at least two benefits:

1. Reusing the same media for multiple early dialogs would be easier to do automatically, without the application needing to know anything about it.
2. WebRTC.MediaHandler.getRemoteStreams could return the early media streams if available, and the on-call streams otherwise (again, without the application having to dig out the early dialog and its streams).

Hi,

it's me again ;). It would be very nice if you could provide your library as bower package 😄

This is a general issue for discussing mobile support for SIP.js. See alongubkin/phonertc#7

See the http example in Section 2.1 of RFC 3515:

Refer-To: http://www.ietf.org

However, attempting to send such a REFER by calling session.refer('http://www.ietf.org') throws a TypeError when the target fails to normalize to a SIP(S) URI.

Also, receiving such a REFER would also fail because the grammar currently does not parse non-SIP URIs in the Refer-To header.

https://tools.ietf.org/html/rfc3892

I believe basic support for this can be achieved application-side, but @funkycode suggested that including default behavior may be nice. From an API perspective, I could see this as an option passed to the refer() method, as well as an optional argument to followRefer() for the referee to opt in or out when copying the headers over.

See the original pull request for some commentary and code:

#77

I don't know if this is a bug.

I use the Kamailio Sip Server and need to add a callback for message events before the SIP-REGISTER:

var test = function(message) {
    console.log('Got message');
};
userAgent.on('message', test);

var callback = function(e) {
    console.log('Got register');
};
userAgent.once('registered', callback);
userAgent.register();

When we switch these events now

var callback = function(e) {
    console.log('Got register');
};

userAgent.once('registered', callback);
userAgent.register();

var test = function(message) {
    console.log('Got message');
};
userAgent.on('message', test);

the Register does not contain the Allow: MESSAGE and Kamailio skips the Message until a new Register is send to the server. Therefore all messages between userAgent.on('message', test); and the reregister are lost.

Greetings
Djcd

Hi Guys! I'm trying to help Joseph test his mobile support. In the process, I was attempting to get a FreeSwitch server set up just to test vanilla SIP.js, however, I can't get SIP.js to connect to the websocket. It just is stuck in the "Pending" state forever. I've verified that I have WS support in Freeswitch enabled and have disabled the firewall, but still no luck.

I'm using v1.4.beta branch. Does anyone know if there is something obvious I'm missing?

This probably depends on #34, but it would be very convenient to bring this boilerplate code into the library:

mediaHint.remoteDisplay = myVideoElement;
mediaHint.localDisplay = myOtherVideoElement;

MediaHandler.setDescription(success, failure, mediaHint); // When available, attach streams to elements.

How can I get caller id before accepting the call?

Sorry, I didn't find solution in docs, guides and during quick overview the source

I have some code that I'm testing in Node. After setting up the UA (SIP.js 0.6.1), I do

ua.on('invite', function(session) {
  session.reject();
});

And then I send an INVITE to my UA. But when my UA receives the INVITE, SIP.js logs

Tue Jul 22 2014 14:14:55 GMT-0700 (PDT) | sip.ua | INVITE received but WebRTC is not supported

And then I get the following error:

Uncaught TypeError: Cannot call method 'receiveResponse' of null
 at Object.IncomingRequest.reply (sip.js/dist/sip.js:4083:27)
 at Object.UA.receiveRequest (sip.js/dist/sip.js:8842:19)
 at Object.Transport.onMessage (sip.js/dist/sip.js:8106:17)
 ...

request.reply(488) in UA.prototype.receiveRequest fails because the server_transaction on the IncomingRequest is null. But really, I'd like to be able to reject() the INVITE before SIP.js sends the 488.

Thanks to Kair on the mailing list for finding this one. In the event of a network failure (e.g., turning Wifi off), the UA continues attempting to recover the transport, with no (good) way of breaking the cycle. Even stopping the UA does not prevent it from trying.

I'm guessing the fix for this is either to stop recovering the transport if the UA is stopped, although there were several other quirks about the network recovery behavior.

Hi guys!

I'm curious how others are approaching playing a ringback tone when making calls. Currently I don't get any audio until a call is actually connected. Do I need to manually play an audio file locally, or should I be hearing early media from my FS server?

Might be a dumb question, apologies if it is!

If SIP.js receives an in-dialog Invite with new SDP it tries to update the Peer Connection. In Chrome 34 this causes the Peer Connection to crash.

Mon May 19 2014 11:47:02 GMT-0400 (EDT) | sip.invitecontext.mediahandler | peerConnection.setLocalDescription failed sip-0.5.0.js:168
Mon May 19 2014 11:47:02 GMT-0400 (EDT) | sip.invitecontext.mediahandler | Failed to set local answer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set audio receive codecs.. 

I think that we should handle this case before SIP.js tries to set new SDP on the Peer Connection so that it does not try to update the SDP.

Hi Guys. What version is the SIP.js demo phone running? When I use it to accept a call from PSTN->FreeSWITCH->DemoPhone it works great and I get 2-way audio. However, when I go from PSTN->FreeSWITCH->MyLocalApp I'm only getting 1-way audio (PSTN side can hear me, but browser side can't hear them).

My Local App is running "sip.js": "0.5.0+bower". I've looked at the code from the Demo Phone and can't find anything significantly different that could be causing this.

Any tips?

#38 was merged in without tests because I was having trouble getting the testing setup to cooperate. I was going to re-open the pull request, but there doesn't seem to be a way to do that, so here's a ticket instead.

We should test that creating an InviteClientContext/InviteServerContext with {mediaHanderFactory: SIP.WebRTC.MediaHandler.defaultFactory} actually ensures that the SIP.WebRTC.* methods are defined.

Using the current master branch of SIP.js on both sides of the call.

If the caller puts the call on hold, hold/resume works great. However if the recipient of the call puts the call on hold, it turns into an INVITE/ACK loop. It looks like the caller side isn't noticing the ACK, so the recipient side keeps sending the INVITE. And so on. This goes on until the ACK timeout kicks in and ends the call.

Let me know if you need anymore information, better logs, etc.

I've added an example of the INVITE/ACK loop below. (These packets are from the caller side) :

sip-0.5.0.js:168
Mon May 05 2014 17:25:04 GMT-0400 (EDT) | sip.transport | sending WebSocket message:

SIP/2.0 200 OK
Via: SIP/2.0/WS 38.101.17.161;branch=z9hG4bKe0a3.7851f9e1.0
Via: SIP/2.0/WS gtf423cseabl.invalid;rport=50173;received=72.64.129.133;branch=z9hG4bK280403
To: sip:[email protected];tag=fm4eu7i2rj
From: "ws2" sip:[email protected];tag=ekrulilh4a
Call-ID: c3bvq677970qgkqmcc5n
CSeq: 8608 INVITE
Contact: sip:[email protected];gr=urn:uuid:2895ed1f-21e1-48fa-a495-fa285a157f72
Supported: gruu,outbound
Content-Type: application/sdp
Content-Length: 2194

v=0
o=- 8774960189842969587 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS CByLqPrgLDG430X9kJcVdPAh7l80FAgkxcFL
m=audio 63998 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 72.64.129.133
a=rtcp:63998 IN IP4 72.64.129.133
a=candidate:3934755452 1 udp 2113937151 10.3.1.34 63998 typ host generation 0
a=candidate:3934755452 2 udp 2113937151 10.3.1.34 63998 typ host generation 0
a=candidate:2819253492 1 udp 1845501695 72.64.129.133 63998 typ srflx raddr 10.3.1.34 rport 63998 generation 0
a=candidate:2819253492 2 udp 1845501695 72.64.129.133 63998 typ srflx raddr 10.3.1.34 rport 63998 generation 0
a=candidate:2751751820 1 tcp 1509957375 10.3.1.34 0 typ host generation 0
a=candidate:2751751820 2 tcp 1509957375 10.3.1.34 0 typ host generation 0
a=ice-ufrag:pLndoGbuL4gLARri
a=ice-pwd:fUevfgt5H7ZIvfyu9h0LHrmP
a=fingerprint:sha-256 B0:D9:D0:A8:E9:09:5A:09:83:D2:51:B9:77:DD:D6:87:F3:4F:98:A0:FE:92:B1:87:24:AC:87:A4:C6:30:C3:23
a=setup:passive
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:4182389599 cname:YpP0KdY624KG+5d4
a=ssrc:4182389599 msid:CByLqPrgLDG430X9kJcVdPAh7l80FAgkxcFL 5798c099-111b-4d82-8093-9cb37e5961d8
a=ssrc:4182389599 mslabel:CByLqPrgLDG430X9kJcVdPAh7l80FAgkxcFL
a=ssrc:4182389599 label:5798c099-111b-4d82-8093-9cb37e5961d8
m=video 1 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:pLndoGbuL4gLARri
a=ice-pwd:fUevfgt5H7ZIvfyu9h0LHrmP
a=fingerprint:sha-256 B0:D9:D0:A8:E9:09:5A:09:83:D2:51:B9:77:DD:D6:87:F3:4F:98:A0:FE:92:B1:87:24:AC:87:A4:C6:30:C3:23
a=setup:passive
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=recvonly
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000

sip-0.5.0.js:168
Mon May 05 2014 17:25:04 GMT-0400 (EDT) | sip.transport | received WebSocket text message:

ACK sip:[email protected];gr=urn:uuid:2895ed1f-21e1-48fa-a495-fa285a157f72 SIP/2.0
Via: SIP/2.0/WS 38.101.17.161;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/WS gtf423cseabl.invalid;rport=50173;received=72.64.129.133;branch=z9hG4bK9518782
Max-Forwards: 16
To: sip:[email protected];tag=fm4eu7i2rj
From: "ws2" sip:[email protected];tag=ekrulilh4a
Call-ID: c3bvq677970qgkqmcc5n
CSeq: 8608 ACK
Supported: outbound
User-Agent: SIP.js/0.5.0-devel
Content-Length: 0

sip-0.5.0.js:168
Mon May 05 2014 17:25:05 GMT-0400 (EDT) | sip.transaction.ict | z9hG4bK4873201 | Timer M expired for INVITE client transaction z9hG4bK4873201 sip-0.5.0.js:168
Mon May 05 2014 17:25:05 GMT-0400 (EDT) | sip.transaction.ict | z9hG4bK4873201 | emitting event stateChanged sip-0.5.0.js:168
Mon May 05 2014 17:25:05 GMT-0400 (EDT) | sip.ua | emitting event transactionDestroyed sip-0.5.0.js:168
Mon May 05 2014 17:25:08 GMT-0400 (EDT) | sip.transport | sending WebSocket message:

SIP/2.0 200 OK
Via: SIP/2.0/WS 38.101.17.161;branch=z9hG4bKe0a3.7851f9e1.0
Via: SIP/2.0/WS gtf423cseabl.invalid;rport=50173;received=72.64.129.133;branch=z9hG4bK280403
To: sip:[email protected];tag=fm4eu7i2rj
From: "ws2" sip:[email protected];tag=ekrulilh4a
Call-ID: c3bvq677970qgkqmcc5n
CSeq: 8608 INVITE
Contact: sip:[email protected];gr=urn:uuid:2895ed1f-21e1-48fa-a495-fa285a157f72
Supported: gruu,outbound
Content-Type: application/sdp
Content-Length: 2194

v=0
o=- 8774960189842969587 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS CByLqPrgLDG430X9kJcVdPAh7l80FAgkxcFL
m=audio 63998 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 72.64.129.133
a=rtcp:63998 IN IP4 72.64.129.133
a=candidate:3934755452 1 udp 2113937151 10.3.1.34 63998 typ host generation 0
a=candidate:3934755452 2 udp 2113937151 10.3.1.34 63998 typ host generation 0
a=candidate:2819253492 1 udp 1845501695 72.64.129.133 63998 typ srflx raddr 10.3.1.34 rport 63998 generation 0
a=candidate:2819253492 2 udp 1845501695 72.64.129.133 63998 typ srflx raddr 10.3.1.34 rport 63998 generation 0
a=candidate:2751751820 1 tcp 1509957375 10.3.1.34 0 typ host generation 0
a=candidate:2751751820 2 tcp 1509957375 10.3.1.34 0 typ host generation 0
a=ice-ufrag:pLndoGbuL4gLARri
a=ice-pwd:fUevfgt5H7ZIvfyu9h0LHrmP
a=fingerprint:sha-256 B0:D9:D0:A8:E9:09:5A:09:83:D2:51:B9:77:DD:D6:87:F3:4F:98:A0:FE:92:B1:87:24:AC:87:A4:C6:30:C3:23
a=setup:passive
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:4182389599 cname:YpP0KdY624KG+5d4
a=ssrc:4182389599 msid:CByLqPrgLDG430X9kJcVdPAh7l80FAgkxcFL 5798c099-111b-4d82-8093-9cb37e5961d8
a=ssrc:4182389599 mslabel:CByLqPrgLDG430X9kJcVdPAh7l80FAgkxcFL
a=ssrc:4182389599 label:5798c099-111b-4d82-8093-9cb37e5961d8
m=video 1 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:pLndoGbuL4gLARri
a=ice-pwd:fUevfgt5H7ZIvfyu9h0LHrmP
a=fingerprint:sha-256 B0:D9:D0:A8:E9:09:5A:09:83:D2:51:B9:77:DD:D6:87:F3:4F:98:A0:FE:92:B1:87:24:AC:87:A4:C6:30:C3:23
a=setup:passive
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=recvonly
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000

sip-0.5.0.js:168
Mon May 05 2014 17:25:08 GMT-0400 (EDT) | sip.transport | received WebSocket text message:

ACK sip:[email protected];gr=urn:uuid:2895ed1f-21e1-48fa-a495-fa285a157f72 SIP/2.0
Via: SIP/2.0/WS 38.101.17.161;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/WS gtf423cseabl.invalid;rport=50173;received=72.64.129.133;branch=z9hG4bK6223582
Max-Forwards: 16
To: sip:[email protected];tag=fm4eu7i2rj
From: "ws2" sip:[email protected];tag=ekrulilh4a
Call-ID: c3bvq677970qgkqmcc5n
CSeq: 8608 ACK
Supported: outbound
User-Agent: SIP.js/0.5.0-devel
Content-Length: 0

sip-0.5.0.js:168
Mon May 05 2014 17:25:12 GMT-0400 (EDT) | sip.transport | sending WebSocket message:

SIP/2.0 200 OK
Via: SIP/2.0/WS 38.101.17.161;branch=z9hG4bKe0a3.7851f9e1.0
Via: SIP/2.0/WS gtf423cseabl.invalid;rport=50173;received=72.64.129.133;branch=z9hG4bK280403
To: sip:[email protected];tag=fm4eu7i2rj
From: "ws2" sip:[email protected];tag=ekrulilh4a
Call-ID: c3bvq677970qgkqmcc5n
CSeq: 8608 INVITE
Contact: sip:[email protected];gr=urn:uuid:2895ed1f-21e1-48fa-a495-fa285a157f72
Supported: gruu,outbound
Content-Type: application/sdp
Content-Length: 2194

v=0
o=- 8774960189842969587 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS CByLqPrgLDG430X9kJcVdPAh7l80FAgkxcFL
m=audio 63998 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 72.64.129.133
a=rtcp:63998 IN IP4 72.64.129.133
a=candidate:3934755452 1 udp 2113937151 10.3.1.34 63998 typ host generation 0
a=candidate:3934755452 2 udp 2113937151 10.3.1.34 63998 typ host generation 0
a=candidate:2819253492 1 udp 1845501695 72.64.129.133 63998 typ srflx raddr 10.3.1.34 rport 63998 generation 0
a=candidate:2819253492 2 udp 1845501695 72.64.129.133 63998 typ srflx raddr 10.3.1.34 rport 63998 generation 0
a=candidate:2751751820 1 tcp 1509957375 10.3.1.34 0 typ host generation 0
a=candidate:2751751820 2 tcp 1509957375 10.3.1.34 0 typ host generation 0
a=ice-ufrag:pLndoGbuL4gLARri
a=ice-pwd:fUevfgt5H7ZIvfyu9h0LHrmP
a=fingerprint:sha-256 B0:D9:D0:A8:E9:09:5A:09:83:D2:51:B9:77:DD:D6:87:F3:4F:98:A0:FE:92:B1:87:24:AC:87:A4:C6:30:C3:23
a=setup:passive
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:4182389599 cname:YpP0KdY624KG+5d4
a=ssrc:4182389599 msid:CByLqPrgLDG430X9kJcVdPAh7l80FAgkxcFL 5798c099-111b-4d82-8093-9cb37e5961d8
a=ssrc:4182389599 mslabel:CByLqPrgLDG430X9kJcVdPAh7l80FAgkxcFL
a=ssrc:4182389599 label:5798c099-111b-4d82-8093-9cb37e5961d8
m=video 1 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:pLndoGbuL4gLARri
a=ice-pwd:fUevfgt5H7ZIvfyu9h0LHrmP
a=fingerprint:sha-256 B0:D9:D0:A8:E9:09:5A:09:83:D2:51:B9:77:DD:D6:87:F3:4F:98:A0:FE:92:B1:87:24:AC:87:A4:C6:30:C3:23
a=setup:passive
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=recvonly
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000

sip-0.5.0.js:168
Mon May 05 2014 17:25:12 GMT-0400 (EDT) | sip.transport | received WebSocket text message:

ACK sip:[email protected];gr=urn:uuid:2895ed1f-21e1-48fa-a495-fa285a157f72 SIP/2.0
Via: SIP/2.0/WS 38.101.17.161;branch=z9hG4bKcydzigwkX
Via: SIP/2.0/WS gtf423cseabl.invalid;rport=50173;received=72.64.129.133;branch=z9hG4bK3750483
Max-Forwards: 16
To: sip:[email protected];tag=fm4eu7i2rj
From: "ws2" sip:[email protected];tag=ekrulilh4a
Call-ID: c3bvq677970qgkqmcc5n
CSeq: 8608 ACK
Supported: outbound
User-Agent: SIP.js/0.5.0-devel
Content-Length: 0

It is possible to receive REFER requests as initial, out-of-dialog requests. Some phone systems use this mechanism for third party call control behavior of some kind. At the moment, SIP.js will reject the request with 405 Method Not Allowed.

I believe this would be possible to implement similarly to our MESSAGE handling. That is, we add a ua.on('refer', callback) event. If the application defines such a callback, call it. Otherwise, reject with 405.

As for the actual behavior of the REFER, check RFC 3515. It should be similar to in-dialog REFER, although we probably don't want to provide the convenience method. Doing so would encourage applications to implement this behavior without prompting the user. Per the RFC, the user SHOULD be prompted for permission.

FreeSwitch by default has Session Timeouts in the SIP headers. This header is documented in RFC4028

Session-Expires: 120;refresher=uas

The re-invites from FreeSwitch have identical SDP to what it sent on the original 200 OK (answer to the INVITE). We should be able to handle it by just sending a 200 OK with the SDP from the original INVITE. No ports or IP addresses have changed.

One potential issue I could see with this is if FreeSwitch decides to update the SDP to use a different IP address or Port. SIP.js has no way of updating the Peer Connection