A PUBLISH request must contain an Expires header field and a Min-Expires

header field. The Expires header field indicates the maximum time when the
ESC may discard the event state information, unless it is updated or refreshed.
The Min-Expires header field indicates the minimum expiration that the ESC
may choose.
Using the entity-tag, the publisher can update a previously published state
In NOTIFY , presence state will be mentioned in
<presence><rpid:others>BUSY><rpid:others><presence>
Same Cseq will be used for Redirect server INVITE and immediate INVITE to proxy
but branch parameter will be differ
CANCEL will only be used to cancel the Pending INVITE requests
Retransmissions will not be used for TCP transport
In PUBLISH , presence state will be mentioned in <state> tag
To put call in HOLD
A=sendonly a=recvonly
A=inactive a=inactive
C=0.0.0.0
C=0.0.0.0
Only proxies send 483 too many hops responses
Media Gateway will be used to manage the media; MG controller will be used
to control the signalling b/n two separate networks.
Session name must not be empty in SDP
If the Req-URI in OPTIONS is Proxys then the req. for Proxy otherwise for User
Agent
A successful SUBSCRIBE establishes a dialog b/n UAC and UAS and expires for
how long that subscription is valid. To unsubscribe make Expire=0.
Subscription-State: terminated, reason=rejected
NOTIFY for subscribe should have the same dialog of the SUBSCRIBE.
Subscription-state: active, pending or terminated
A PUBLISH request is similar to a NOTIFY, except it is not sent in a dialog
MESSAGEs may be sent within a dialog or outside a dialog, but they do not
establish a dialog by themselves
The UPDATE method [29] is used to modify the state of a session without
changing the state of the dialog
488 Not accepted here response for unsupported CODECs

Via is used to find the loops

Record route is used for to store the path
Strict routing it changes the Req URI of each hop and must forwards through
listed proxy only
Loose Routingit doesnt change the req uri of each hop and should go through
all the proxies other proxies also can be inserted.

In the Early Offer process, the calling sends the SDP information within the SIP
INVITE message. The callee answers in the SIP 200 OK message.
In the Delayed Offer process, the calling does not send its offer in the SIP INVITE
Message. The callee sends the offer within the SDP fields of its answer (SIP 200
OK). The calling answers within the ACK message.
"Early media" refers to the process where the media channel is set up before
the callee picks up the phone.
Generally 180 generate local ringing. For example, if the call fails, the SIP calling
will not be aware of the failure: the ringing tones will still be generated to the
end-user. To avoid this 183 session progress which gets the packets from called
party and plays at caller to know path is established
BYE and the response to the BYE would allow Late Media to be sent from the
UAC to the UAS.
Expires header field in 302 response indicates, how much time the contact is
valid.
400 Bad Request- If mandatory header field is missing
401 Unauthorised- For registrar and redirect servers
404 Not found- Request URI is not located
407 Proxy Auth Required- For proxies only
415 Unsupported Media Type
416Unspported Req. URI
420 Bad Extension- Require Header field extension doesnt support
480 temporarly unavailable---for redirect not available
481 Dialog doesnt exist
482 Loop detected
483 Too many hops
486 Busy Here
487 Request Terminated

505-version not supported

This response indicates that the request has been refused by the server because
of
the SIP version number of the request. The detailed semantics of this response
have not yet been defi ned because there is only one version of SIP (version 2.0)
currently implemented. When additional version numbers are implemented in
the future, the mechanisms for dealing with multiple protocol versions will need
to be detailed.

606-Not acceptable anywhere

UPDATE Method:
Caller

Callee
|
|
|
|
|(1) INVITE with offer 1
|
|---------------------------->|
|
|
|
|
|(2) 180 with answer 1
|
|<----------------------------|
|
|
|
|
|(3) PRACK
|
|---------------------------->|
|
|
|
|
|(4) 200 PRACK
|
|<----------------------------|
|
|
|
|
|(5) UPDATE with offer 2
|
|---------------------------->|
|
|
|
|
|(6) 200 UPDATE with answer 2 |
|<----------------------------|
|
|
|
|
|(7) UPDATE with offer 3
|
|<----------------------------|
|
|
|
|
|(8) 200 UPDATE with answer 3 |
|---------------------------->|
|
|
|
|
|(9) 200 INVITE
|
|<----------------------------|
|
|
|
|
|(10) ACK
|

|---------------------------->|
|
|
|
|
|
|
|
|
Figure 1: UPDATE Call Flow
PUBLISH Method:
PUBLISH requests create, modify, and remove event state associated with an
address-of-record.
A Publish request does not establish a dialog.
Identification of published event state is provided by three pieces of information:
Request-URI, event type, and (optionally) an entity-tag.
For each successful PUBLISH request, the ESC will generate and assign an
entity-tag and return it in the SIP-ETag header field of the 2xx response.
PUBLISH requests MUST contain a single SIP-If-Match header field identifying the
specific event state that the request is refreshing, modifying or removing.
An initial PUBLISH request MUST contain a body that contains the published
event state.
Request-URI of a PUBLISH request is populated with the address of the resource
for
which the user wishes to publish event state. The user may in turn have
multiple User Agents or endpoints that publish event state.

181 call forwarding will have reason header; reason: redirection, cause=5,
text=immediate
407,416 ,482,483 will be checked by proxies. If not matched, these responses
will be sent.

Session Border Controllers: